AMENDMENTS TO THE DRAWINGS 



Applicant has amended FIGs. 6-10 to include the legend "Prior Art." No 
new matter has been added. 

The attached replacement sheets designated as FIGs. 6-10 replace the original 
sheets designated as FIGs. 6-10. 
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REMARKS 



In the Official Action mailed on 23 August 2005 the Examiner reviewed 
claims 67-70. The abstract was objected to for being too long. The drawings 
were objected to. Claims 67 and 69 were objected to under 35 U.S.C. §101 
because they are directed to non-statutory subject matter. Claims 69-70 were 
rejected under 35 U.S.C. §103(a) as being unpatentable over Gligor 
(USPub 2001/0033656, hereinafter "Gligor") in view of Jutla {Encryption Modes 
with Almost Free Message Integrity, August 2000, hereinafter "Jutla"), in further 
view of Menezes, {Handbook of Applied Cryptography, 1997, hereinafter 
"Menezes"). 

Objection to the Abstract 

The abstract was objected to for being too long. 

Applicant has supplied a new Abstract that is within the 150 word limit. 
No new matter has been added. 

Objections to the Drawings 

The drawings were objected to because FIGs. 6-10 were not marked as 
"prior art." 

Applicant has amended FIGs. 6-10 to include the proper markings. No 
new matter has been added. 

Rejections under 35 U.S.C, §101 

Claims 67 and 69 were objected to because they are directed to non- 
statutory subject matter. 

Applicant has amended claims 67 and 69 to incorporate the suggestions of 
the Examiner. 
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Rejections under 35 U.S.C. §1 03(a) 

Claims 69-70 were rejected as being unpatentable over Gligor in view of 
Jutla in further view of Menezes. 

Applicant respectfully disagrees that claims 69-70 are obvious in view of 
Gligor, Jutla, and Menezes. A paper by the Applicant on offset codebook (OCB) 

th 

encryption was accepted into a competitive conference on cryptography, The 8 
ACM Conference on Computer and Communications Security (commonly referred 
to as the ACM CCS conference), a well-regarded venue with an acceptance rate 
(for the year in question, 2001) of 18%. The paper's only significant contribution 
is the OCB scheme — the same scheme that is narrowly described by claims 69-70. 
The OCB scheme is clearly described in the ACM CCS paper as being an 
improvement to the work of Gligor and Jutla, work that was known in the 
inventor's community at the time of the ACM CCS submission and was clearly 
referenced in the paper. If the cryptographic community viewed the subject 
claims as obvious in view of Gligor and Jutla and Menezes, the paper would most 
certainly not have been accepted. A copy of the inventor's ACM CCS paper is 
included with this response. 

The inventor's ACM CCS paper above was regarded as one of the top 
papers at the conference and was therefore invited to a well-respected journal, 
ACM Transactions on Information and Systems Security (ACM TISSEC), where 
it underwent additional review and subsequently appeared. If the inventor's 
community viewed the subject claims as obvious in view of Gligor, Jutla, and 
Menezes, the paper would not have been invited into a well-regarded journal. The 
inventor's ACM TISSEC paper is included with this response. 

Additionally, the commercial community has already decided that OCB is 
non-obvious: the method has been licensed multiple times, yielding 6-figure 
earnings, to medium and large companies. The attorneys at these companies 
know that there is pending IP of Gligor and Jutla (both VDG Inc. and IBM have 
made public disclosures in connection with activities at NIST, the IEEE, and other 
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venues) and yet they have chosen to license OCB, never expressing any concern 
that the patent claims would be seen as obvious given prior work. 

The Applicant, knowing intimately the contents of Gligor et al and Jutla 
and the book by Menezes et al, spent months of intensive effort to develop the 
disclosed methods, as narrowly defined by the subject claims. Many attempts 
failed: there were 14 unpublished versions of OCB, many of which had subtle 
bugs that took weeks to discover by the inventor or the coauthors of his papers. 
The inventor and his coauthors are of more than ordinary skill in the art; the 
inventor is a well-known cryptographer with more than 3000 references to his 
papers, and the winner of the RSA Prize in Mathematics. He did not find the 
method described by the claims as obvious, nor did co-author Mihir Bellare, who 
is widely regarded as the top cryptographer of his generation. 

Gligor's patent application makes clear that his only idea for handling 
messages that were not a multiple of the block length was to use padding (e.g., 
10* pad the final block to make it a multiple of the block length, and then 
continue by using the padded message). Gligor's patent application mentions no 
less than seven times that messages that have a length other than the block length 
are to be padded as necessary to get them to be a multiple of the block length. No 
other approach is mentioned, and, in fact, padding is the only obvious approach to 
correctly deal with this issue. It was a first goal of the subject patent application 
to deal with messages that are not a multiple of the block length by a method 
smarter than the obvious padding approach: messages not a multiple of the block 
length are not padded in the disclosed technique. 

Alternatives to padding that one might initially think of do not work 
because they break the authenticity protection in subtle ways. This is true for 
many other potential refinements to the schemes of Jutla and Gligor et al, too. As 
explained in the ACM CCS paper, "We have found schemes of this sort to be 
amazingly "fragile" — tweak them a little and they break." Representative 
examples of such breaks are given the "Definition of the checksum" paragraph 
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and the "Avoiding pretag collisions" paragraphs on pp. 201-202 of the inventor's 
ACM CCS paper. Applicant maintains that a method is non-obvious when 
schemes that are very close to it have subtle errors. 

Jutla and Gligor et al provided to NIST the most efficient schemes they 
knew how to construct. Their proposals are less efficient than OCB according to 
multiple metrics, as described in the descriptive portion of the subject patent 
application. It is not reasonable to assume that Jutla or Gligor themselves 
regarded as obvious the techniques described in the pending patent application 
that could have made their proposals more efficient. 

There are technical difficulties with the Examiner's reading of claims 
69-70 against Gligor, Jutla, and Menezes. In particular, items (h) and (j) on p. 5 
of the Examiner's office action are not analogous to Menezes p. 340, while item 
(k) is not analogous to Gligor [0025], Regarding (h) and (j), the examiner's refers 
to the Matyas-Meyer-Oseas hash function, a classical method to construct a hash 
function from a block cipher. There is no length-encoding used in this hash 
function, and there is no xoring of a portion of a block cipher output with a string 
having length possibly less than the length of the block cipher. It is simply a 
chaining method, like CBC encryption. As for item (k), Gligor [0025] mentions 
padding in an unrelated context — as a way to ensure that all messages acted on in 
Gligor' s scheme have length that is a multiple of n bits (denoted as "I" bits by 
Gligor). Such padding aims to solve a problem solved by the current patent 
application — handling messages that are not a multiple of the block size — but it 
does so at a cost of longer ciphertexts. The padding in (k) of the patent 
application is taking a fragment (something less than n bits) and adding bits (e.g. 
0-bits) simply in order to feed it into the checksum calculation — a checksum 
calculation that would not work correctly if, for example, a padded message 
fragment were directly used. This is unrelated to Gligor' s initial padding of the 
input message where he aims to avoid otherwise dealing with "peculiar-length" 
strings. 
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Finally, Applicant comments that in providing a block-cipher-based 
cryptographic mode of operation (whether for encryption, message authentication, 
authenticated encryption, collision-intractable hashing, or some other end), 
anything one does is going to be a combining of basic building blocks (apply the 
block cipher, xor the following words, partition a message, add some padding, 
combine the following strings, and so forth). The non-obvious part is finding the 
right way to combine basic operational elements in order to more simply and 
efficiently accomplish some cryptographic task. In this domain, specious 
approaches are common and finding a correct way to meld basic building blocks 
can be highly non-obvious. 

Applicant has amended claims 69 and 70 to clarify that the present 
invention encrypts messages of arbitrary length into a ciphertext of the same 
length. These amendments find support on page 24, line 32 to page 25, line 7 of 
the instant application. 

Hence, Applicant respectfully submits that independent claims 67-70 are 
in condition for allowance. 
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CONCLUSION 



It is submitted that the present application is presently in form for 
allowance. Such action is respectfully requested. 



Edward J. Grundler 

PARK, VAUGHAN & FLEMING LLP 

2820 Fifth Street 

Davis, CA 95616-7759 

Tel: (530) 759-1663 

FAX: (530) 759-1665 

Email: edward@parklegal.com 




Respectfully submitted. 



By 



Edward J. Grundler 
Registration No. 47,615 



Date: 6 October 2005 
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We describe a parallelizable block-cipher mode of operation that simultaneously provides privacy 
and authenticity. OCB encrypts-and-authenticates a nonempty string M € {0, 1}* using \\M |/n] + 2 
block-cipher invocations, where n is the block length of the underlying block cipher. Additional over- 
head is small. OCB refines a scheme, IAPM, suggested by Charanjit Jutla. Desirable properties 
of OCB include the ability to encrypt a bit string of arbitrary length into a ciphertext of mini- 
mal length, cheap offset calculations, cheap key setup, a single underlying cryptographic key, no 
extended-precision addition, a nearly optimal number of block-cipher calls, and no requirement 
for a random IV. We prove OCB secure, quantifying the adversary's ability to violate the mode's 
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1. INTRODUCTION 

Background. An authenticated-encryption scheme is a shared-key encryp- 
tion scheme whose goal is to provide both privacy and authenticity. The en- 
cryption algorithm takes a key, a plaintext, and an initialization vector (IV), 
and it returns a ciphertext. The decryption algorithm takes a key, a cipher- 
text, and an IV, and it returns either a plaintext or a special symbol, Invalid. 
We refer to the IV as the nonce, to reflect the requirements we will make 
on it. In addition to the customary privacy goal, an authenticated-encryption 
scheme aims for authenticity: if an adversary should try to create some 
new ciphertext, the decryption algorithm will almost certainly regard it as 
Invalid. 

An authenticated-encryption scheme can be constructed by appropriately 
combining an encryption scheme and a message authentication code (MAC), an 
approach used pervasively in practice and in standards. (Analyses of such meth- 
ods are provided in Bellare and Namprempre [2000] and Krawczyk [2001] .) But 
an attractive and long-standing goal has been an authenticated-encryption 
scheme having computational cost significantly lower than the cost to en- 
crypt plus the cost to MAC. The classical approach for trying to do this is 
to encrypt-with-redundancy, where one appends a noncryptographic check- 
sum to the message before encrypting it, typically with CBC mode. Many 
such schemes have been broken. Recently, however, Charanjit Jutla has pro- 
posed two authenticated-encryption schemes supported by a claim of prov- 
able security [Jutla 2001a]; Gligor and Donescu [2002] then described a dif- 
ferent authenticated-encryption scheme. We continue in this line of work. See 
the Appendix for further history. 

OCB Mode. This paper describes a new mode of operation, OCB, which re- 
fines one of Jutla's schemes, IAPM [Jutla 2001a]. OCB (which stands for "offset 
codebook") retains the principal characteristics of IAPM: it is fully paralleliz- 
able and adds minor overhead compared to conventional, privacy-only modes. 
But OCB combines the following additional features: 

— Arbitrary -length messages -f minimal-length ciphertexts. Any string M e 
{0, 1}* can be encrypted; in particular, \M\ need not be a multiple of the block 
length n. What is more, the resulting ciphertexts are as short as possible. 

— Minimal TV requirements. Like other encryption modes, OCB requires an IV. 
The entity that encrypts chooses a new IV for every message with the only 
restriction that no IV is used twice. We henceforth refer to the IV as the 
nonce. 

— Nearly optimal number of block-cipher calls. OCB uses r|M|/n] + 2 block- 
cipher invocations to encrypt- and-authenticate a nonempty message M. 

— Single underlying key. The key used for OCB is a single block-cipher key, and 
all block-cipher invocations are keyed by this one key. 

— Efficient offset calculations. As with other recent methods, we require a se- 
quence of offsets. We generate them in a particularly cheap way, each offset 
requiring a few machine cycles and no extended-precision arithmetic. 
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Achieving the properties above requires putting together a variety of "tricks" 
that work together in just the right way. Many plausible-looking constructions 
that we considered turned out to be wrong. 

Performance. Experiments by Lipmaa [2001] on a Pentium III processor 
show that OCB is about 6.5% slower than the privacy-only mode CBC, and 
about 54% the speed of CBC encryption combined with the CBC MAC. These 
figures assume a block cipher of AES128 [US National Institute of Standards 
2001]. 

In settings where there is adequate opportunity for parallelism, OCB will be 
faster than CBC. Parallelizability is important for obtaining the highest speeds 
from special-purpose hardware, and it may become useful on commodity proces- 
sors. For special-purpose hardware, one may want to encrypt-and-authenticate 
at speeds near 10 Gb/s — an impossible task, with today's technology, for modes 
like CBC encryption and the CBC MAC. (One could always create a mode that 
interleaves message blocks fed into separate CBC encryption or CBC MAC cal- 
culations, but that would be a new mode, and one with many drawbacks.) For 
commodity processors, there is an architectural trend toward highly pipelined 
machines with multiple instruction pipes and lots of registers. Optimally ex- 
ploiting such features necessitates algorithms that have plenty to do in parallel. 

Security Properties. We prove OCB secure, in the sense of reduction- 
based cryptography. Specifically, we prove indistinguishability under chosen- 
plaintext attack [Bellare et al. 1997; Goldwasser and Micali 1984] and authen- 
ticity of ciphertexts [Bellare and Namprempre 2000; Bellare and Rogaway 2000; 
Katz and Yung 2000b] . This combination implies indistinguishability under the 
strongest form of chosen-ciphertext attack (CCA) and that, in turn, is equivalent 
to nonmalleability under CCA [Bellare et al. 1998; Bellare and Namprempre 
2000; Dolev et al. 2000; Katz and Yung 2000a, 2000b] . (Nonmalleability refers to 
an adversary's inability to modify a ciphertext in a way that makes related the 
two underlying plaintexts.) Our proof of privacy assumes that the underlying 
block cipher is good in the sense of a pseudorandom permutation (PRP) [Bellare 
et al. 2000; Luby and Rackoff 1988], while our proof of authenticity assumes 
that the block cipher is a strong PRP [Luby and Rackoff 1988]. Our results are 
quantitative; the security analysis is in the concrete-security paradigm. 

We emphasize that OCB has stronger security properties than standard 
modes. In particular, nonmalleability and indistinguishabihty under CCA are 
not achieved by CBC, or by any other standard mode, but these properties are 
achieved by OCB. We believe that the lack of strong security properties has 
been a problem for the standard modes of operation, because many users of en- 
cryption implicitly assume these properties when designing their protocols. For 
example, it is common to see protocols that use symmetric encryption in order 
to "bind together" the parts of a plaintext, or that encrypt related messages as 
a way to do a "handshake." Standard modes do not support such practices. This 
fact has sometimes led practitioners to incorrectly apply the standard modes, 
or to invent or select wrong ways to try to encrypt with authenticity (a well- 
known example is the use of PCBC mode [Meyer and Matyas 1982] in Kerberos 
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v.4 [Steiner et al. 1988]). We believe that authenticated-encryption modes are 
less likely to be misused because many common ways of using a mode of oper- 
ation that are incorrect when the mode provides privacy only become correct 
when it provides both privacy and authenticity. 

By way of comparison, a chosen-ciphertext attack by Bleichenbacher on the 
public-key encryption scheme of RSA PKCS #1, v. 1.5, motivated the company 
that controls this de facto standard to promptly upgrade its scheme [Bleichen- 
bacher 1998; RSA Laboratories 1998]. In this public-key setting, it was even 
a concern if misimplementations could lead to effective attack [Manger 2001]. 
In contrast, people seem to accept as a matter of course symmetric encryption 
schemes that are not even nonmalleable. This may be changing, as it becomes 
clear how damaging and widespread side-channel and chosen-ciphertext at- 
tacks can be [Black and Urtubia 2002; Vaudenay 2002]. 

2. PRELIMINARIES 

Notation, If a and b are integers, a < b, then [a. .6] is the set {a, a + 1, . . . , b). 
If i > 1 is an integer then ntz(i) is the number of trailing 0-bits in the binary 
representation of i (equivalently, ntz(i) is the largest integer z such that 2 Z 
divides i). So, for example, ntz(7) = 0 and ntz(8) = 3. 

A string is a finite sequence of symbols, each symbol being 0 or 1. The string 
of length 0 is called the empty string and is denoted e. Let {0, 1}* denote the 
set of all strings. If A, B e {0, 1}* then AB, or A\\B, is their concatenation. 
If A e {0, 1}* and A^s then firstbit(A) is the first bit of A and lastbit(A) is the 
last bit of A. Let i 9 n be nonnegative integers. Then 0* and V denote the strings of 
i 0s and Is, respectively. Let {0, l} n denote the set of all strings of length n. If A e 
{0, 1}* then |A| denotes the length of A, in bits, while ||A|| n = max{l, r|A|/n]} 
denotes the length of A in n-bit blocks, where the empty string counts as one 
block. For A e {0, 1}* and |A| < n, zpad n (A) is the string A 0 n ~ |A| . With n 
understood we will write AO* for zpad n (A). If A € {0, 1}* and x e [0..|A|] then 
A [first r bits] and A [last r bits] denote the first r bits of A and the last r bits 
of A, respectively. Both of these values are the empty string if x == 0. If A, B e 
{0, 1}* then A ® B is the bitwise xor of A [first i bits] and B [first t bits] , where 
t = min{|A|, (where e0 A = A® e = e). So, for example, 1001® 11 = 01. If 
€ {0, l} rt then str2num(A) is the number Ya=o 2 ' a i- If a > 0 is 
a number then num2str n (a) is the n-bit string A such that str2num(A) = a. Let 
len rt (A) = num2str n (|A| mod 2 n ). We omit the subscript when n is understood. 
Note that if | A| > 2 n (which, in practice, will never happen) then len„(A) does 
not encode all of \A\ (since we do not have enough bits). 

If A = a n -\a n -2 • ■ • a\ao e {0, 1}" then the n-bit string a n _2a„_ 3 • . • aiaoO, de- 
noted A<z 1, is a left shift of A by 1 bit (the first bit of A disappearing and a zero 
coming into the last bit), while A»l is the n-bit string 0an_ia n _2 • * ■ a%a\ that 
is a right shift of A by 1 bit (the last bit disappearing and a zero coming into 
the first bit). 

In pseudocode we write "Partition M into M[l] * • • M [m] n as shorthand for 
"let m = ||M |U and let M [1] , . . . , M [m] be strings such that M [1] • • . M [m] = M 
and \M[i]\ = n for 1 < i < m." We write "Partition C into C[l] • -C[m] T" 
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as shorthand for "if \C\ < r then return Invalid. Otherwise, let C = 
C [first |C| - r bits], let T = C [last r bits], let m = \\C\\ n , and let C[l], . . . , C[m] 
be strings such that C[l] • • • C[m] = C and |C[z] | = n for 1 < i < m." Recall that 
|| M || n = max{l, \\M\/ri\ }, so the empty string partitions into m = 1 block, that 
one block being the empty string. 

The Field with 2 n Points. Let GF(2") denote the field with 2 n points. We 
interchangeably think of a point a in GF(2 n ) in any of the following ways: (1) as 
an abstract point in a field; (2) as an 7i-bit string a n _i • • -a\a^ e {0, l} n ; (3) as 

a formal polynomial a(x) = a n -ix n ~ x ^ f- a\x + ao with binary coefficients; 

(4) as an integer between 0 and 2 n — 1, where the string a e {0, 1}" corresponds 
to the number str2num(a). For example, one can regard the string a = 0 125 101 
as a 128-bit string, as the number 5, as the polynomial x 2 + 1, or as an abstract 
point in GF(2 128 ). We write a(x) instead of a if we wish to emphasize that we 
are thinking of a as a polynomial. 

To add two points in GF(2 n ), take their bitwise xor. We denote this operation 
by a ® b. To multiply two points in the field, first fix an irreducible polyno- 
mial /? n (x) having binary coefficients and degree n: say the lexicographically 
first polynomial among the irreducible degree n polynomials having a mini- 
mum number of nonzero coefficients. For n = 128, the indicated polynomial is 
Pi2s(x) = x 128 +x 7 +x 2 +x+l.Some other p n (x)-values arex 64 +x 4 +x 3 +x+l (for 
n = 64) and x 256 + x 10 + x 5 -f x 2 + 1 (for n = 256). To multiply a, b e GF(2 n ), which 

we denote a * 6, regard a and b as polynomials a(x) = a n -\yL n ~ l H h aix + ao 

and b(x) = 6 n _ix n_1 H h &ix + 6 0) form their product c(x) over GF(2), and take 

the remainder one gets when dividing c(x) by p n (x). 

It is computationally simple to multiply a e {0, l} n by x. We illustrate the 
method for n = 128, in which case multiplying a = a n _i ■ * aiao by x yields 
a„_ix n + a n _2x n " 1 +aix 2 + aox. Thus, if the first bit of a is 0, then a • x = a<cl. If 
the first bit of a is 1 then we must add x 128 to a<:l. Since pi28(x) = x 128 + x 7 + 
x 2 + x 4- 1 = 0 we know that x 128 = x 7 + x 2 + x + 1, so adding x 128 means to xor 
by 0 120 10000 111. In summary, when n = 128, 



It is similarly easy to divide a e {0, 1} by x (i.e., to multiply a by the 
multiplicative inverse of x). If the last bit of a is 0, then a • x" 1 is a»l. If the 
last bit of a is 1 then we must add (xor) to a»l the value x" 1 . Since x 128 = 
x 7 + x 2 -f-x + l we have that x" 1 = x 127 + x 6 + x + l = 10 120 1000011. In summary, 
when n — 128, 



Note that the point huge = x 1 is a large number (when viewed as< such); in 
particular, it starts with a 1 bit, so huge > 2 n_1 . 




a<s:l if firstbit(a) = 0 

(a<e:l)e0 120 10000111 if firstbit(a) = 1. 




a;s>l if lastbit(a) = 0 

(a»l)el0 120 1000011 if lastbit(a) = 1. 
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If L e {0, l} n and i > —1, we write L(i) as shorthand for L * x l . Using the 
equations just given, we have an easy way to compute from L the values L(— 1), 
L(0), L(l), . . ., L(/z), where /x is a small number. 

Gray Codes. For t > 1, a Gray code is an ordering y l = (y£ y( ... K^-i^ 
of {0, 1}* such that successive points differ (in the Hamming sense) by just 1 
bit. For n a fixed number, OCB makes use of the "canonical" Gray code y — y n 
constructed by y 1 = (0 1) and, for t > 0, 

Y t+l = (0yt 0y/...0y£_ 2 Oy^ ly^ x ly£_ 2 - ly' ltf). 

It is easy to see that y is a Gray code. What is more, for 1 < i < 2 n — 1, 
= y t _ x ® (0 n_1 l<s:nt2(£)). This makes it easy to compute successive points. 
We emphasize these characteristics of the Gray-code values yi, y2, . . . , y2»-i: 

that they are distinct and different from 0; that yi = 1; and that yi <2i. 

Let L € {0, l} n and consider the problem of successively forming the strings 

yi * L, y2 • L, y3 * L, . . . , y m • L. Of course y\ • L = 1 * L = L. Now, for i > 2, assume 

one has already produced y;_i • L. Since yt = y^i 0 (0 n_1 l^:ntz(i)), we know 

that 

yi L = (yj.! © (O^l^ntztf))) • L 

= (w-i-De^l^ntztfW-L 

= (yi-rL)e(L.x nb(i) ) 

= (w-i-L)©L(ntz(i)). 

That is, the ith word in the sequence yi * L, yi • L, y3 • L, . . . is obtained by xoring 
the previous word with L(ntz(i)). Had the sequence we were considering been 
yi • L © R, yi • L 0 R, y$ • L 0 U, . . . , the ith word would be formed in the same 
way for i > 2, but the first word in the sequence would have been L © R instead 
ofL. 

3. THE SCHEME 

Parameters. To use OCB one must specify a block cipher and a tag length. 
The block cipher is a function £:Kx(0, l} n {0, l} n , where each E(K 9 •) = 
Ek(-) is a permutation on {0, 1}". Here K is the set of possible keys (a finite 
nonempty set) and n is the block length. We insist that n > 64 and discourage 
n < 128. The tag length is an integer r e [0..n]. By trivial means, the adversary 
will be able to forge a valid ciphertext with probability 2~ T . The popular block 
cipher to use with OCB is likely to be AES [US National Institute of Standards 
2001]. As for the tag length, a suggested default of r = 64 is reasonable. Tags 
of 32 bits are standard in retail banking. Tags of 96 bits are used in IPSec. 
Using a tag of more than 80 bits adds questionable security benefit, though it 
does lengthen each ciphertext. 

We let OCB-2? denote the OCB mode of operation using block cipher E and 
an unspecified tag length. We let OCB[iJ , r] denote the OCB mode of operation 
using block cipher E and tag length t. 
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Nonces. Encryption under OCB mode requires an n-bit nonce, N. The nonce 
would typically be a counter (maintained by the sender) or a random value (se- 
lected by the sender). Security is maintained even if the adversary can control 
the nonce, subject to the constraint that no nonce may be repeated within the 
current session (that is, during the period of use of the current encryption key). 
The nonce need not be random, unpredictable, or secret. 

The nonce N is needed both to encrypt and to decrypt. Typically it would 
be communicated, in the clear, along with the ciphertext. However, it is out- 
of-scope how the nonce is communicated to the party who will decrypt. In par- 
ticular, we do not regard the nonce as part of the ciphertext. 

Definition of the Mode. See Figure 1 for a definition and illustration of OCB. 
The figure defines OCB encryption and decryption. The key space for OCB is 
the key space JC for the underlying block cipher E. 

An Equivalent Description. The following description may clarify what a 
typical implementation might do. 

(1) Key Generation: Choose a random key K «£- K for the block cipher. The 
key K is provided to both the entity that encrypts and the entity that 
decrypts. 

(2) Key Setup: For the party that encrypts, do any key setup associated with 
block-cipher enciphering. For the party that decrypts, do any key setup 
associated with block-cipher enciphering and deciphering. Let L <- Ex(O n ). 
Let m bound the maximum number of /i-bit blocks that any message that 
will be encrypted or decrypted may have. Let \i <- flog 2 m\ . Let L(0) <- L 
and, for i e [l..fi], compute L(i) <- L(i — 1) * x using a shift and a conditional 
xor, as described in Section 2. Compute L{— 1) <- L * x" 1 using a shift and 
a conditional xor, as described in Section 2. Save the values L(-l), L(0), 
L(l), . . . , L(fji) in a table. 

(3) Encryption: To encrypt plaintext M e {0, 1}* using key K and nonce 
N e {0, l} n , obtaining a ciphertext C, do the following. Let m «- \\M\/ri\. 
If m = 0 then let m <- 1. Let Mil], . . . , M[m] be strings such that 
M[l]..-M[m) = M and \M[i]\ = n for i e [l..m - 1]. Let Offset <- 
E K (N © L). Let Checksum <- 0*. For i <- 1 to m - 1, do the following: 
let Checksum <- Checksum ffi Af [£]; let Offset «- Offset ® L(ntz(i)); let 
C[i] <- E K (M[i] © Offset) © Offset. Now let Offset <- Offset © L(ntz(m)). 
Letyfrn] ^-£^(len(M[7n])©L(-l)©Offset).LetC[m] <- M [m] xored with 
the first |M [m] | bits of Y[m]. Let Checksum «- Checksum ©y[m]©C[m] 0*. 
Let T be the first r bits of Er (Checksum © Offset). The ciphertext is 
C = C[l] • ■ -C[m - l]C[m] T. It must be communicated along with the 
nonce N. 

(4) Decryption: To decrypt ciphertext C G {0, 1}* using key K and nonce N e 
{0, 1} B , obtaining a plaintext M e {0, 1}* or an indication Invalid, do the 
following. If \C\ < x then return Invalid (the ciphertext has been rejected). 
Otherwise let C be the first \C\ - r bits of C and let T be the remaining t bits. 
Let m <- \\C\/ri\. If m = 0 then let m <- 1. Let C[l], . . . , C[m] be strings 
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M[l) 



M[2] 



j M[m — 1]| | M lm][ 



E K 








E K 



CM I | C[2] I 



E K 



L • x- 

$4— Z[m-1] ty+-Z[m] 
X[m] 



i^t-Z[r, 



E K 



| C[m - 1] | | C[m]| 



rln ~ 



Algorithm OCB.Encjr (TV, M) 


Algorithm OCB.DeCic (JV, C) 


Partition M into M[l] • ■ • M[m] 


Partition 6 into C[l] • - ■ C[m] T 


L<-£ic(0») 


L^E K (0 n ) 




R +— Ek (N © L) 


for i «— 1 to m do Z[i] = fi - L® R 


for i <— 1 to m do = 7* ■ L © R 


for i <- 1 to m - 1 do 


for i <— 1 to m — 1 do 


C[t] <- £?jc(Af[i] © Z[i]) © Z[i] 




X[m] <- len(M[m]) © L • x _1 © Z[m] 


X[m] <- len(C[m]) © L • x" 1 © Z[m] 


Y[m] - EjctA-H) 


Y[m] <- E K (X[m]) 


C[m] <- y[m] © M[m] 


M[m] <- y[m] © C[m] 


C<-C[l]-.-C[m] 


M +- M[l] • ■ -M[m] 


Checksum 


Checksum <— 


M[l] © . . © M[m - 1] © C[m] 0* © y[m] 


Af[l] © • ■ • © M[m - 1] © C[m]0* © Y[m] 


T <- £?if (Checksum © Z[m]) [first r bits] 


T ^(Checksum © Z[m]) [first r bits] 
if T = V then return M 

else return Invalid 


return e <- C || T 



Fig. 1. OCB encryption. The message to encrypt is M and the key is K. Message M is written 
as U = M[1]M[2] ■ - M[m - l]M[m], where m = maxjl, |W|/ral) and \M[1]\ = \M[2)\ = • •• = 
|M[m - 1]| = n. Nonce Af is a nonrepeating value selected by the party that encrypts. It, along 
with ciphertext C = C[1JC[2]C[3] ■ ■ C[m - l]C[m] T, is needed to decrypt. The Checksum is 
M[l]© - ©M[m-l]©C[/n]0*©y[m].OfFsetZ[l] = L©J? while, fori > 2,Z[i] = 2[i-l]®L(ntz(i)). 
String L is defined by applying Ek to the fixed string 0". For Y[m] © M\m) and Y[m\ © C[m], 
truncate y [m] if it is longer than the other operand. By C[m] 0* we mean C[m] padded on the right 
with 0-bits to get to length n. Function len represents the length of its argument, mod 2 n , as an 
rc-bit string. 

such that C[l] • • • C[m] = C and \C[i]\ = n for i e [l..m - 1]. Let Offset <e- 
Ek(N 0 L). Let Checksum <- 0 n . For t <- 1 to m - 1, do the following: 
let Offset <r- Offset 0 L(ntz(£)); let M[i] <- E^(C[i] 0 Offset) 0 Offset; let 
Checksum <- Checksum 0 M[i]. Now let Offset «- Offset 0 L(ntz(m)). Let 
y [m] <- jEjf(len(C[ml)©L(-l)eOfFset). Let M[/n] <- C[m] xored with the 
first \C[m]\ bits of Y[m). Let Checksum <- Checksum 0 Y [m] 0 C[m] 0*. 
Let T' be the first r bits of ^(Checksum 0 Offset). IfT^T 1 then return 
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Invalid (the ciphertext has been rejected). Otherwise, the plaintext is M = 
M[l]-.-M[m-l]M[m]. 

4. DISCUSSION 

OCB has been designed to have a variety of desirable properties. We mention 
some of those properties here. 

Arbitrary-Length Messages and Minimal Ciphertext Expansion. One of the 
key characteristics of OCB is that any string M e {0, 1}* can be encrypted, and 
doing this yields a ciphertext C having \M | + x bits. That is, the length of the 
"ciphertext core" — the portion C = C[l] • • • C[m] of the ciphertext that excludes 
the tag — is the same as the length of the message M . This is better, by up to n 
bits, than what one gets with conventional padding. But remember that we 
do not regard the nonce as part of the ciphertext. Including it, the amount of 
information that needs to be sent to the receiver is \M\ + x + r\ bits, where r) 
bits are used to communicate the nonce N. The value of 77 could be anything in 
[0..n], depending on the application. 

Single Block-Cipher Key. OCB makes use of just one block-cipher key, K. 
While L — Ek(O h ) functions rather like a key and would normally be computed 
at key-setup time, and while standard key-separation techniques can always 
be used to obtain many keys from one, the point is that, in OCB, all block-cipher 
invocations use the one key K . Thus only one block-cipher key needs to be setup, 
saving on storage space and key-setup time. 

Weak Nonce Requirements. We believe that modes of operation that require 
a random IV are often misused. As an example, consider CBC mode, where 
C[i] = E K (M[i] ® C[i - 1]) and C[0] = IV. Some standards and books suggest 
that the IV may be a fixed value, a counter, a timestamp, or the last block 
of ciphertext from the previous message. But if it is any of these things, one 
certainly will not achieve any of the standard definitions of privacy [Bellare 
et al. 1997; Goldwasser and Micali 1984]. 

It is sometimes suggested that a mode that needs a random IV is preferable 
to one that needs a nonce: it is said that state is needed for a nonce, but not for 
making random bits. We find this argument wrong. First, a random value of 
sufficient length can always be used as a nonce, but a nonce cannot be used as 
a random value. Second, the manner in which systems provide "random" IVs 
is invariably stateful anyway: unpredictable bits are too expensive to harvest 
for each IV, so one does this rarely, using state to generate pseudorandom bits 
from unpredictable bits harvested before. Third, the way to generate pseudo- 
random bits needs to use cryptography, so the prevalence of noncryptographic 
pseudorandom number generators routinely results in implementation errors. 
Fourth, nonce-based schemes facilitate simple replay-detection. Finally, nonces 
can be communicated using fewer bits than random values. 

On-Line. OCB encryption is on-line : one can output a stream of ciphertext 
bits as a stream of plaintext bits arrive, the output stream having constant 
latency and the transformation using constant memory. When one receives an 
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indication that the plaintext is over, the final chunk of ciphertext is output. One 
need not know the length of the plaintext in advance of processing it. This allows 
the efficient encryption of strings whose representation uses a special character 
(e.g., a zero-byte) to indicate the string's end. An incremental interface (in the 
style popular for cryptographic hash functions) could be used to support this 
functionality. 

OCB decryption is likewise on-line, but with an important difference: one can 
produce a stream of plaintext bits as the stream of ciphertext bits comes in, but 
when the ciphertext stream is finished one may need to "cancel" the plaintext 
stream that has issued (having found the ciphertext to be invalid). In such a 
case, nothing about the ciphertext (such as what was the canceled plaintext) 
should be adversarially available beyond an indication of its invalidity. In any 
authenticated-encryption scheme, decryption can be on-line only to this extent. 

Significance of Being Efficient. Shaving off a few block-cipher calls or a 
few bytes of ciphertext may not seem important. But often one is dealing with 
short messages; for example, roughly a third of the messages on the Internet 
backbone are 43 bytes. If one is encrypting messages of such short lengths, 
one should be careful about message expansion and extra computational work 
since, by percentage, the inefficiencies can be large. 

The argument has been made that making a major effort to save a factor 
of two in computational efficiency is marginal in the first place: "Moore's law" 
will soon deliver such an improvement anyway, by way of faster hardware. We 
are not persuaded. Along with processors getting faster, security has become 
increasingly an issue, and low-power and embedded processors have become 
more prevalent. The result is a need to cryptographically process more and 
more data, and often by "dumb" execution vehicles. Hardware advances have 
changed our understanding of what efficiency entails but, to date, hardware 
advances have not made cryptographic efficiency less important. 

Endian Neutrality. In contrast to a scheme based on mod-p arithmetic (for p 
a prime near 2 n ) or mod-2" arithmetic, there is almost no endian-favoritism 
implicit in the definition of OCB. (The exception is that, because of our use of 
standard mathematical conventions, the left shift used for forming L(i + 1) from 
L(i) is more convenient under a big-endian convention, as is the right shift used 
for forming L(— 1) = L * x" 1 from L.) 

Optional Preprocessing. Implementations can choose how many L(i) values 
to precompute. Since only one block-cipher call is needed to compute all of the 
L(i) values, plus a shift and a conditional xor for each value, it is feasible to do 
no preprocessing: OCB is appropriate even when each session is a single, short 
message. 

Provable Security. Provable security has become a popular goal for practical 
protocols. This is because it provides the best way to gain assurance that a 
cryptographic scheme does what it is should. For a scheme that enjoys provable 
security one does not need to consider attacks on the scheme, since successful 
ones imply successful attacks on some simpler object. 

ACM Transactions on Information and System Security, Vol. 6, No. 3, August 2003. 



OCB: A Block-Cipher Mode of Operation for Efficient Authenticated Encryption • 375 

When we say that "OCB is provably secure" we are asserting the existence 
of two theorems. One says that if an adversary A could do a good job at forg- 
ing ciphertexts with OCB[2J, r] (the adversary does this much more than a 
2" T fraction of the time) then there would be an adversary B that does a good 
job at distinguishing (Ek (•), E^i-)), for a random key K, from (7r( ), 7r _1 ( )), 
for a random permutation jt € Perm(n). The other theorem says that if an 
adversary A could do a good job at distinguishing OCB[2J, r] -encrypted mes- 
sages from random strings, then there would be an adversary B that does a 
good job at distinguishing E K (-), for a random key K, from tt(-), for a random 
permutation n e Perm(n). Theorems of this sort are called reductions. In cryp- 
tography, provable security means giving reductions (along with the associated 
definitions). 

Provable security begins with Goldwasser and Micali [1984]. The style of 
provable security that we use here— where the primitive is a block cipher, the 
scheme is a mode of operation, and the analysis is concrete (no asymptotics) — is 
the approach of Bellare and Rogaway [Bellare et al. 1995; 1997; 2000]. 

It is not enough to know that there is a provable-security result; one should 
also understand the definitions and the bounds. We have already sketched the 
definitions. When we speak of the bounds we are addressing "how effective is 
the adversary B in terms of the efficacy of adversary A" (where A and B are as 
above). For OCB, the bounds can be roughly summarized as follows: an adver- 
sary can always forge with probability l/2 r . Beyond this, the maximal added 
advantage is at most o 2 /2 n , where a is the total number of blocks the adversary 
sees. The privacy bound likewise degrades as a 2 /2 n . The conclusion is that one 
is safe using OCB as long as the underlying block cipher is secure and a is 
small compared to 2 n/2 . This is the same security degradation one observes for 
CBC encryption and in the bound for the CBC MAC, as shown by Bellare et al. 
[1997; 2000] . This kind of security loss was the main motivation for choosing a 
block length for AES of n = 128 bits. 

Comparison with Jutla's Bound. More precisely, but still ignoring lower- 
order terms, our privacy and authenticity bounds are 1.5 a 2 /2 n , while Jutla's 
authenticity bound is insignificantly worse at 2a 2 /2 n and his privacy bound, 
rescaled to [0, 1], is insignificantly worse at 3o 2 /2 n [Jutla 2001b]. Magnify- 
ing the latter difference is that the privacy results assume different defini- 
tions. Jutla adopts the find-then-guess definition of privacy [Bellare et al. 
1997; Goldwasser and Micali 1984], while we use an indistinguishability-from- 
random-bits definition. The former captures an adversary's inability to distin- 
guish ciphertexts for a pair of adversarially selected, equal-length plaintexts. 
The latter captures an adversary's inability to distinguish a ciphertext from a 
random string of the same length. Indistinguishability-from-random-bits im- 
plies find-then-guess security, and by a tight reduction, but find-then-guess se- 
cure does not imply indistinguishability-from-random-bits. Still, Jutla's scheme 

probably satisfies the stronger definition, and with similar bounds. 

#■ 

Numerical Example to Illustrate Provable Security. Let us do a small exam- 
ple to illustrate what, concretely, the provable-security results mean. Suppose 
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that we are using OCB-AES, tags are 64 bits (or longer), and the adversary has 
access to at most 2 40 bytes of chosen ciphertext before the key is changed (by 
a new key-exchange, for example). Then, if AES has its anticipated security, 
the adversary's chance to produce a valid forged message (after studying its 
1 TB of acquired data) is around 1.5 (2 40 " 4 ) 2 /2 128 + 2" 64 < 2~ 55 . In general, the 
l.5a 2 /2 n formula provides guidance in how long a key can be used safely The 
considerations are application-dependent, but one needs to change keys well 
before 2 n/2 blocks have been encrypted. 

Simplicity. Simplicity has been a central design goal. Some of OCB's charac- 
teristics that contribute to simplicity are (1) short and full final-message-blocks 
are handled uniformly, not splitting into separate cases; (2) only the simplest 
form of padding is used: append a minimal number of O-bits to make a string 
whose length is a multiple of n. This method is computationally fastest, and 
helps avoid a proliferation of cases in the analysis; (3) only one algebraic struc- 
ture is used throughout the algorithm: the finite field GF(2 n ); (4) in forming 
the sequence of offsets, gray-code coefficients are taken monotonically, starting 
at 1 and stopping at m. One never goes back to an earlier offset or forms more 
offsets than there are blocks. 

Not Fixing How the Nonce is Communicated. We do not specify how the 
nonce is chosen or communicated. Formally, it is not part of the ciphertext 
(though the receiving party needs it to decrypt). In many contexts, there is al- 
ready a natural value to use as a nonce (e.g., a sequence number already present 
in a protocol flow, or implicit because the parties are communicating over a re- 
liable channel). Even when a protocol is designed from scratch, the number of 
bits needed to communicate the nonce will vary. In some applications, 32 or 
even 8 bits is enough. For example, one might have reason to believe that there 
are at most 2 32 messages that will flow during the connection, or one may com- 
municate only the lowest 8 bits of a sequence number, counting on the receiver 
to anticipate the high-order bits. 

Not Fixing the Tag Length. The number of bits necessary for the tag vary 
according to the application. In a context where the adversary obtains some- 
thing quite valuable from a successful forgery, one may wish to choose a tag 
length of 80 bits or more. In contexts such as authenticating a video stream, 
where an adversary would have to forge many frames to have a major impact on 
the image, an 8-bit tag may be appropriate. With no universally correct value 
to choose, it is best to leave this parameter unspecified. 

Short tags seem to be more appropriate for OCB than for some other MACs, 
particularly Carter-Wegman MACs. Many Carter-Wegman MACs have the 
property that if you can forge one message with probability S then you can 
forge an arbitrary set of (all correct) messages with probability 8. This does 
not appear to be true for OCB, though we have not investigated formalizing or 
proving such properties. 

Forming R Using a Block-Cipher Call. During our work we discovered 
that there are methods for authenticated-encryption that encrypt M using 
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\\M \fri\ + 1 block-cipher calls, as opposed to our fl M \/ri\ +2 calls. Halevi [2001] 
has also made this finding. However, the methods we know to shave off a block- 
cipher call either require an unpredictable IV instead of a nonce, or they add 
conceptual and computational complexity to compute the initial offset R by 
noncryptographic means (e.g., using a finite-field multiplication of the nonce 
and a key variant). 

Avoiding mod-2 n Addition. Our earlier designs included a scheme based 
on modular 2 n addition ("addition" for the remainder of this paragraph). Bas- 
ing an authenticated-encryption scheme on addition is an interesting idea 
due to Gligor and Donescu [2002]. Compared to our GF(2 n )-based approach 
("xor" for the remainder of this paragraph), an addition-based scheme might 
seem simpler. But the use of addition (where n > 128) has several disadvan- 
tages: (1) The bit-asymmetry of the addition operator implies that the resulting 
scheme will have a bias toward big-endian architectures or little-endian archi- 
tectures; there will be no way to achieve an endian neutral scheme. The AES 
algorithm was constructed to be endian neutral and we wanted OCB-AES to 
inherit this attribute. (2) Addition is unpleasant for implementations using 
high-level languages, where one normally has no access to the add-with-carry 
instruction the machine may have. (3) Addition needs more chip area than xor. 
(4) Some hardware platforms perform addition more slowly than xor. Experi- 
ments on a Pentium 3 revealed that repeated add-with-carry instructions were 
slower than repeated xors. (5) The concrete security bound appears to be worse 
with addition than xor (though still not bad). The degradation would seem to 
be 0(lg/n), where m is the maximal message length. We eventually came to 
believe that the simplicity benefit of addition was not worth it and was not 
real. 

Definition of the Checksum. An initially odd-looking aspect of OCB's defini- 
tion is the definition of Checksum = M [1] 0 • • • M [m — 1] 0 C [m] 0*07 [m] . In 
Jutla's scheme, where one assumes that all messages are a positive multiple of 
the block length, the checksum is the simpler-looking M [1] 0 * • • M[m — 1] 0 
M[m]. We comment that these two definitions are identical in the case that 
|M[m]| = n. What is more, the definition Checksum = M [1] 0 ■ • • M [m — 1] 0 
M [m] 0* turns out to be the wrong way to generalize the Checksum to allow 
for short-final-block messages; in particular, the scheme using that checksum 
is easily attacked. 

5. THEOREMS 

5.1 Security Definitions 

The first provable-security treatment of symmetric encryption is due to Bellare 
et al. [1997]. A provable-security treatment of authenticated encryption was 
initiated by Katz and Yung [2000b] and Bellare and Rogaway [2000] and con- 
tinued by Bellare and Namprempre [2000]. We build on all these works but our 
definitions involve some novel elements. 
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OCB uses a nonce, and we wish to give the adversary every possible advan- 
tage (more than is available in real life) by allowing it to choose this nonce 
(though we forbid the adversary from choosing the same nonce twice). This 
leads us to introduce a new primitive, that we call a nonce-using symmetric en- 
cryption scheme, and that is syntactically different from a standard symmetric 
encryption scheme. We also introduce a new and particularly strong notion of 
privacy called indistinguishability from random strings. 

Syntax. We extend the syntax of an encryption scheme as given in Bellare 
et al. [1997]. A (nonce-using, symmetric) encryption scheme is a triple n = 
(/C, £, V) and an associated number n (the nonce length). Here /C is a finite set 
and £ and V are deterministic algorithms. Encryption algorithm £ takes K e /C, 
N e {0, l} n , and M e {0, 1}*, and returns a string C <- Sk(N, M). Decryption 
algorithm V takes K e JC, N e {0, l} n , and C e {0, 1}*, and returns V K (N, M), 
which is either a string M e {0, 1}* or the distinguished symbol Invalid. If 
C <e- £k(N, M) then V K (N, C) = M. 

Privacy. We give a particularly strong definition of privacy, one assert- 
ing indistinguishability from random strings. This notion is easily seen to 
imply (the natural extension to nonce-using schemes) more standard defini- 
tions [Bellare et al. 1997], and by tight reductions. Consider an adversary A 
that has one of two types of oracles: a "real" encryption oracle or a "fake" en- 
cryption oracle. A real encryption oracle, £k (•, •), takes as input N, M and re- 
turns C «- £k(N, M). Assume that |C| — i(\M\) depends only on |M|. A fake 
encryption oracle, $(•, ), takes as input N,M and returns a random string 
C {0, l}* (|Af|) . Given adversary A and encryption scheme n = (JC, £, V\ define 
Adv£ riv (A) - ¥r\K A JC : A £ ^ = 1] - Vr[K A K : A $( v> = 1]. 

An adversary A is nonce-respecting if it never repeats a nonce: if A asks its 
oracle a query (iV, M) it will never subsequently ask its oracle a query (N> M'), 
regardless of its coins (if any) and regardless of oracle responses. All adversaries 
are assumed to be nonce respecting. 

Authenticity. We extend the notion of integrity of ciphertexts of Bellare 
and Namprempre [2000], Bellare and Rogaway [2000] and Katz and Yung 
[2000b]. Fix an encryption scheme n = (/C, £, V) and run an adversary A 
with an oracle £k(-, •) for some key K. Adversary A forges (in this run) if A is 
nonce respecting, A outputs (N,C), where T>k(N,C) # Invalid, and A made 
no earlier query (iV, M) that resulted in a response C. Let Advn Uth (A) = 
PrLK: 4- JC : A £k( ^ forges]. We stress that the nonce used in the forgery attempt 
may coincide with a nonce used in one of the adversary's queries. 

Block Ciphers and PRFs. A function family from n-bits to ra-bits is a map 
E : /C x {0, 1}* {0, l} n , where K is a finite set of strings. It is a block cipher if 
each Ek (*) = E(K t •) is a permutation. Let Rand(n) denote the set of all func- 
tions from {0, 1}" to {0, l} n , and let Perm(n) denote the set of all permutations 
from {0, l} n to {0, l} rt . These sets can be regarded as function families by imag- 
ining that each member is specified by a string. For n e Perm(ra), let n~ l (Y) be 
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the unique string X such that n(X ) = Y . Let 

Adv£ f (A) = Pr[K 4- K : A** 0) = 1] - Pr[p 4- Rand(n) : A> (,) = 1] 
Advg^A) = ?r[K 4- /C : A**° = 1] - Prfr 4- Perm(n) : A 7r( ) = 1] 
Adv^ prp (A) = ¥r[K £ JC : A** 0 '** 0 = 1] 

- Pr [jt 4- Perm(n) : A 7r( ' ),7r ~ 1( ) = 1] 

be defined for a block cipher E and adversary A. 
5.2 Theorem Statements 

We give information-theoretic bounds on the authenticity and the privacy of 
OCB. Proofs are in Section 8. 

Theorem 5.1 (Authenticity). Fix OCB parameters n and r. Let A be an ad- 
versary that asks q queries and then makes its forgery attempt Suppose the q 
queries have aggregate length of a blocks, and the adversary's forgery attempt 
has at most c blocks. Let a — a + 2q + 5c + 11. Then 

A j auth / A \ ^ 1.5 (X 2 1 

Aav OCB[Perm(7i),T] W - 2 » 2* * 

The aggregate length of queries Mi, . . . , M q means the number a = 

It is standard to pass to a complexity-theoretic analog of Theorem 5.1, but 
in doing this one will need access to an B" 1 oracle in order to verify a forgery 
attempt, which translates into needing the strong PRP assumption. One gets 
the following. Fix OCB parameters n and t, and a block cipher E : /C x {0, 1}" 
{0, l} n . Let A be an adversary that asks q queries and then makes its forgery 
attempt. Suppose the q queries have aggregate length of a blocks, and the 
adversary's forgery attempt has at most c blocks. Let a = or + 2g4-5c + ll. 
Let 8 = AdvocI[£,r] < A ) " 15 * 2 /2 n - 1/2 T . Then there is an adversary B for 
attacking block cipher E that achieves advantage Adv^^CB) > S. Adversary B 
asks at most g ; = a + 2g+c-f3 oracle queries and has a running time that is 
equal to A's running time plus the time to compute E or E~ l at q f points plus 
additional time that is ana, where the constant a depends only on details of 
the model of computation. 

The privacy of OCB is given by the following result. 

Theorem 5.2 (Privacy). Fix OCB parameters n and r. Let A be an adversary 
that asks q queries, these having aggregate length of a blocks. Let a = a +2q -f-3. 
Then 

Adv pnv (A) < 

Aav OCB[Perm(n),r] - 2* ' 

As before, it is standard to pass to a complexity-theoretic analog of 
Theorem 5.2. Fix OCB parameters n and t, and a block cipher E : K, x {0, l} n -» 
{0,1}". Let A be an adversary that asks q queries, these having aggregate length 
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15.9 (255) 


15.9 (256) 
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19.2 (307) 


16.3 (261) 


15.5 (248) 


15.3 (246) 



Fig. 2. Performance results from Lipmaa [2001], in cycles per byte (cycles per 16-byte block) on a 
Pentium III. The block cipher is AES128. Code is written in assembly. 

of a blocks.Let a = a + 2g + 3. Let 8 = AdvocBUs.r] < A > ~ L5a 2 /2 n . Then 
there is an adversary B for attacking block cipher E that achieves advantage 
Adv^d?) > 8. Adversary B asks at most q f = a + 2q + 1 oracle queries and 
has a running time that is equal to A's running time plus the time to compute 
E at q f points plus additional time that is ana, where the constant a depends 
only on details of the model of computation. 

6. PERFORMANCE 

Abstract Accounting. OCB uses f|M|/n] + 2 block-cipher calls to encrypt a 
nonempty message M . (The empty string takes three block-cipher calls.) 

We compare this with CBC encryption and CBC encryption plus a CBC MAC. 
Namely, "basic" CBC encryption, where one assumes a random IV and a mes- 
sage which is a multiple of the block length, uses \M\/n block-cipher calls. 
(A more fair comparison uses some padding regime and sets IV = Ek>(N), 
so both schemes use a nonce IV). If one combines basic CBC encryption with a 
CBC MAC, say MACing the ciphertext (including the IV), then CBC-encryption 
will use a number of block-cipher calls as just discussed, while the CBC MAC 
will use at least C|M + 1 block-cipher calls (possibly more, depending on 
padding conventions and what is done to ensure security across messages 
of varying lengths). So the total number of calls for CBC encryption with a 
CBC MAC will be at least 2r|M|//il + 1, and typically a bit more. 

As with any mode, OCB has overhead beyond the block-cipher calls. Per- 
block, this overhead is about four n-bit xor operations, plus associated logic. 
The work for this associated logic will vary according to whether or not one 
precomputed L(i)-values and many additional details. 

Though some or all of the needed L(i)-values are likely to be precomputed, 
computing all of them "on the fly" is not inefficient. Starting with 0" we form 
successive offsets by xoring the previous offset with L, 2 • L, L, 4 • L, L, 2 • L, L, 
8 • L, and so forth. So half the time we use L itself; a quarter of the time we use 
2 • L; one eighth of the time we use 4 • L; and so forth. Thus the expected number 
of times to multiply by x in order to compute an offset is at most YaLi = 1- 

Each a • x instruction requires an n-bit shift and a conditional 32-bit xor. Said 
differently, for any m > 0, the total number of a x operations needed to compute 
yi • L, y2 * L y . . . , Ym • L is YaLi ntz(i), which is less than m. 

Experimental Results. In Figure 2 we report, with permission, some exper- 
imental results by Lipmaa [2001]. On a Pentium III, in optimized assembly, 
Lipmaa implemented OCB encryption, ECB encryption, CBC encryption, and 
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the CBC MAC. The last three modes were implemented in their "raw" forms, 
where one does no padding and assumes that the message acted on is a positive 
multiple of the block length. For CBC encryption, the IV is fixed. The underlying 
block cipher is AES128. 

Focusing on messages of 1 KB, OCB incurs about 6.4% overhead compared to 
CBC encryption, and the algorithm takes about 54% of the time of a CBC encryp- 
tion + CBC MAC. Lipmaa points out that overhead is so low that, in his experi- 
ments, an assembly AES128 with a C-code CBC-wrapper is slightly slower than 
the same AES128 with an assembly OCB-wrapper. Lipmaa's (size-unoptimized) 
code is 7.2 KB, which includes unrolling AES 128 (2.2 KB) three times. 

Some aspects of the experiments above are unfavorable to OCB, making the 
performance estimates conservative. In particular, the "raw" CBC MAC needs 
to be modified to correctly handle length variability; when combined with CBC 
encryption, the CBC MAC should be taken over the full ciphertext, including the 
nonce, which would add an extra block-cipher call; and an extra block-cipher call 
would normally be performed by CBC to correctly compute the IV from a nonce. 

The results above are for a serial execution environment. In settings with 
plenty of registers and multiple instruction pipes, OCB, properly implemented, 
will be faster than CBC. 

7. AFTERWARDS 

After the initial publication of OCB, many individuals pointed out that often 
times when one is trying to encrypt a message with authenticity there is ad- 
ditional data, such as a message header, that should be authenticated but not 
encrypted. The associated data should be bound to the ciphertext but should 
not increase its length. This problem of authenticated encryption with associ- 
ated data has been formally defined in Rogaway [2002], and an extension to 
OCB has been given there that allows the binding-in of arbitrary associated 
data while retaining OCB's efficiency characteristics. 

Schroeppel [2001] has described to us a nice implementation trick that ob- 
viates the utility of the Gray-code ordering used in OCB. The method is to pre- 
compute the sequence £(0), L(l), L(2), £(3), . . . = L, 3L, 7L, 15L, • • • instead 
of L(0), L(l), L(2), L(3), . . . = L,2L, 4L, 8L, . . . . Then note that values of the 
sequence L, 2L, 3L, 4L, 5L, . . . can be efficiently enumerated using the obser- 
vation that iL = (i - 1)L © £(ntz(£)) for any i > 2. 

OCB has become an optional algorithm in a draft IEEE 802.11 standard for 
the security of wireless LANs. 

The authenticated-encryption schemes of Gligor and Donescu [2002], Jutla 
[2001a], and Rogaway et al. [2001b] all have patents pending. See the first 
author's web page for current information. 

8. PROOFS 

8.1 Structure of the Proofs 

Our proof of Theorem 5.1 is based on three lemmas. The first, the structure 
lemma, relates the authenticity of OCB to three functions: the M-collision 
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probability, denoted Mcoll n (), the MM-collision probability, denoted 
MMcoll„0, •), and the CM-collision probability, denoted CMcoll n (-, •). We 
state this lemma and then explain its purpose and the functions to which it 
refers. 

Lemma 1 (Structure Lemma). Fix OCB parameters n and r. Let A be an 
adversary that asks q queries and then makes its forgery attempt. Suppose the q 
queries have aggregate length of a blocks, and the adversary's forgery attempt 
has at most c blocks. Let a = a + 2q + 5c + 11. Let Mcoll n ( ), MMcoll n (-, crnd 
CMcoll„(-, •) be the M-, MM-, and CM-collision probabilities, respectively. Then 



What This Lemma Does. The structure lemma provides a recipe for measur- 
ing the maximal forging probability of an adversary attacking the authenticity 
of OCB: compute the M-, MM-, and CM- collision probabilities, and then put 
them together using the formula of the lemma. 

Informally, Mcoll n (7n) measures the probability of running into trouble when 
the adversary asks a single query of the specified length. Trouble means the 
occurrence of any collision in the associated block-cipher-input values. This in- 
cludes the "special" input 0" (used to define L = 2?jK0") and JV © L (used to 
define R = E K (N © L)). Informally, MMcoll rt (/n, m) measures the probability 
of running into trouble when the adversary asks some two oracle queries of 
the specified lengths. Trouble means that a block-cipher input associated with 
the first message coincides with a block-cipher input associated with the sec- 
ond message. Informally, CMcoll n (c, m) measures the probability of running 
into trouble when the adversary tries to forge some particular ciphertext C of 
the specified block length c, there having been an earlier query of some par- 
ticular message M of the specified block length m, it receiving some particu- 
lar response. This time trouble basically refers to the final block-cipher input 
for the forgery attempt, X[c + 1], coinciding with some earlier block-cipher 
input. 

The structure lemma simplifies the analysis of OCB in two ways. First, it 
allows one to excise adaptivity as a concern. Dealing with adaptivity is a major 
complicating factor in proofs of this type. Second, it allows one to concentrate 
on what happens to fixed pairs of messages. It is easier to think about what 
happens with two messages than what is happening with all q + 1 of them. 

The M- and MM-Collision Probability. We next define the M-collision prob- 
ability and the MM-collision probability, and then state our upper bound on 
these functions. 



Adv! 
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Definition 8.1 (M- and MM-Collision Probabilities). Fix n > 0 and let 
M = M[0] • • • M[m + 1] and M = M[0] • -Mint + 1] be strings of at least 2n 
bits, where each M[i] and has n bits. Choose L,R,R {0, l} n and then 
associate with M and M the points 

X[-l] = 0" 

X[0] =M[0]eL £[0] =M[0]©L 

=M[1]@/ 1 .L©^ =M[l]©n.L©5 

X[2] =M[2]©y 2 ^©^ ^(2] =M[2]®y 2 ^e5 

X[m - 1] = M[m - 1] © L®R X[m-1] = M[m - 1] © L@R 
X[m] = M[m] © (y m © /iage) • L © X[m] — M[m] © (y^ © /mge) • L © 5 
X[m + 1] = M[m -f 1] © Ym ■ £ © # X[m + 1] = M[m + 1] © y m • L © R 

and the multisets 

X Q = {X[-U, X[0], X[m], Xbn + 1]) 

X = {X[0], X[l],..., X[m], X[m + 1]} 

* = {*[(>], X[l],..., *[m], *[m + l]} 

Let Mcoll n (M ) denote the probability that some string is repeated in the multi- 
set Xq, and let MMcoll a (M, M) denote the probability that some element occurs 
in both X and X. When m and m are numbers, let Mcoll^/n) denote the maxi- 
mal value of Mcoll^(M) over all strings M e ({0, l} n ) m + 2 , and let MMcoll n (m, m) 
denote the maximal value of Mcoll n (M, M) over all M e ({0, l}") 771 * 2 and 
M e ({0, l} n )™+ 2 such that M[0] ^M[0], 

Think of M[0] as a synonym for the nonce N, think of M[m] as a gener- 
alization of len(M[m]) (where the adversary can effectively control M[m] as 
opposed to len(M [m]) to influence X [m]), and think of M [m .+ 1] as a synonym 
for Checksum, which we likewise let the adversary control. One similarly un- 
derstands M[0], M[fh], and M [m + 1] . The needed bound is as follows. 

Lemma 2 (Bound on the M- and MM-Collision Probability). 
Mcoll n (m) < f 2 J • — and MMcoll n (m,m) < — . 

The CM-Collision Probability, The CM-collision probability is defined in 
Figure 3. The following lemma tells us how large it can possibly be. 

Lemma 3 (Bound on the CM-Collision Probability). Assume c, m < 2 n ~ 2 . 
Then 

otv/t n / 2c + 3m + 9 
CMcoll n (c,m) < — . 

Concluding the Authenticity Theorem. To prove Theorem 5.1, combine 
Lemmas 1-3. Let n = OCB[Perm(n), r]. Given the aggregate block length a 
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10 bad <— false; for all x € {0, l} n do tt(x) «— undefined 

11 L^-{0,l} n ; 7r(0 n )<-L 

20 x[o]^-iveL; Y[q] <- £^{o,ir 

21 for i <— 1 to m do <-_7x • L 0 J£ 

22 for 2 <- 1 to m - 1 do { X[i] <- M[i] © Z[i]\ Y[i] +- C[i] © Zji] } 

23 X[m] «- len(M[m]) © huge • L © Z[m] ; Y(fh) «- C[fh] 0* © M[m] 0* 

24 Checksum' <- M[l] © ■ ■ ■ ©_M[m - 1] © C[m] 0* © Y[m] 

25 X[m 4- 1] <- Checksum' © Z[m] 

26 for i «- 0 to m 4- 1 do 7r(X[i]) <- 

30 X[0}^N®L 

31 if TV ^ N and X[0] € Domain (n) then bad true 

32 if N = N then R^R else # *i {0, l} n 

33 ?r(X[0]) <- R 

34 for i 1 to c do Z[i] <- 7< • L © E 

35 for i <- 1 to c - 1 do { 

36 y [i] <- C[i] © Z[i] 

37 if Y[i) € Range(Tr) then X\i] <- 7r~ l (Y[i]) else ^ {0, l} n 

38 7r(X[i]) <- y[i]; M[i] <- © } 

39 X[c] <- len(C[c]) © huge • L © Z[c] 

40 if X[c] € Domain(Tr) then y[c] <- tt(X[c]) else y[c] ^ {0, l} n 

41 *(X[c]) - Y[c] 

42 Checksum <- M[l] © ■ ■ ■ © M[c - 1] © C[c] 0* © Y[c] 

43 X[c+1]*- Checksum © Z[c] 

44 if X"[c 4- 1] 6 Domain(7r) then bad <— true 



Fig. 3. Defining the CM-collision probability. The function CMcoll n (iV, M, C, iV, C) is defined 
as the probability that bad gets set to true when executing this game. The value CMcoll n (c, m) is 
the maximal value of CMcoll„(iv', M,C } N } C) over all m-block M and C, and all c-block C such 
that N ^ ft or C^C. 

and the bound c on the length of the forgery attempt, one must bound the 
maximum possible value of 



Adv* utll (A) < 




r€[l..q] l<r<s<q 



Mcoll n (m r ) + ^2 MMcoll n (m r ,m s ) 
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One can bound the first sum by letting m i = a and letting the remaining m i = 0, 
one can bound the second sum by letting each m; = o/q, and one can bound the 
third sum by letting m\ — a and letting the remaining n%i = 0. These choices 
can be justified by the technique of Lagrange multipliers. This gives 

A , aut h,.x ^ 0.5(q + 3) 2 + 4.5g < Q.5g 2 (<r/<? + 2) 2 t 2c + 3a + 9 + q(2c + 9) 
Adv n {A) < - + - + 

0.5(q+2g + 5c + ll) 2 J_ 
+ 2 n + ¥ 

0.5(<r + 3) 2 + 4.5g + 0.5(a + 2g) 2 + 2c + 3a + 9 + 2cg + 9g + 0.5(a + 2q + 5c + ll) 2 

j_ 0.5(a + 3) 2 + 0.5(q + 2g) 2 + 0.5(a + 2g + 5c + ll) 2 + (3a + 2cq + 2c + 13.5g + 9) 
+ 2 T 5 2" 

1 1.5(q + 2o+5c + ll) 2 1 1.5 a 2 1 

H < 1 < 1 . 

2 T " 2 n 2 T ~ 2 n 2 r 

The fourth inequality is justified by checking that 0.5(a + 3 + (2q + 5c + 8)) 2 - 
0.5(<r + 3) 2 ) already exceeds 3a + 2cg + 2c + 13.5q + 9. This completes the 
proof. □ 

Privacy. Privacy is obtained rather easily en route to proving authenticity. 
This is because of the following result, which closely follows the first half of the 
proof of the structure lemma. 

Lemma 4 [Privacy Lemma] . Fix OCB block length n and tag length x } and let 
n = OCB[Perm(/z), t]. Let A be an adversary that asks q queries, these having 
aggregate block length of a blocks. Let Mcoll„() and MMcoll n (-, •) be the M- and 
MM-collision probabilities. Then 

Advru) a 

+ max I ^2 Mcoll n (m r )+ ^ MMco\l n (m r ,m s )> . 

Y^mi=° \re[\..q] l<r<s<q J 

Combining Lemmas 2 and 4 gives Theorem 5.2. Namely, 

Adv p- (A) < ^yi)^ max f E 

m/>0 

J (m r + 2)(77i 5 + 2) 
+ max < > 

^m;=<7 ^ l<r<s<<? 
mj>0 

ACM Transactions on Information and System Security, Vol, 6, No. 3, August 2003. 



386 • R Rogaway et al. 

and we bound the two sums exactly as before, giving 

AdvS | (A) < — - + + — - — -f-= 

n 2 n 2 n 2 n 

0.5(g + 2q + D 2 + 0.5(g + 3) 2 + 4.5? + 0.5(cr + 2g) 2 + 4.5g 
~ 2 n 

1.5(a+ 2<7 + 3) 2 



< 



2" 

1.5 a 2 



" 2 n 

The third inequality can be justified by noting that 0.5(a + 3 + 2q ) 2 - 0.5(a + 3) 2 
exceeds 4.5q. 

8.2 Proof of the Structure Lemma (Lemma 1) 

Let A be a (computationally unbounded) adversary that attempts to violate the 
authenticity of n = OCB[Perm(n), t]. Without loss of generality, A is deter- 
ministic. The adversary is given an oracle for OCB.Enc^(-, •). We must bound 
the probability that A, after adaptively using this oracle q times, on messages 
with aggregate length a blocks, produces a properly forged ciphertext having 
at most c blocks. This forgery probability is denoted Advn Uth (A). 

Game A. One can conceive of A interacting with OCB.Enc^(-, •) and then 
producing a forgery attempt as A playing a certain game, game A, as defined in 
Figures 4 and 5. Rather than choose n Perm(n) all at once, this game defines 
the values of n(x) point-by-point, as needed. We use the notation Domain(^) for 
the set of values x e {0, l} n such that n (x) ^ undef ined. By Domain(7r ) we mean 
{0, l} rt \ Domain(7r). Similarly, Ranged) is t he set of y e {0, l} n such that there 
exists an x e {0, l} n for which n(x) — y, and Ranged) = {0, 1}" \ Ranged). 

An inspection of game A makes clear that it supplies to A a perfect simulation 
of OCB.EnCjrO, •). Game A simulates OCB in a somewhat unusual way, not only 
defining jr point-by-point, but, when a value n(x) is needed , for some new x y 
we get this value, in most cases, not by choosing y 4- Ranged), as would seem 
natural, but by choosing y 4- {0, l} n , setting n(x) to y if y is n ot already in the 
range of 7r, and "changing our minds," setting n(x) 4- Ranged), otherwise. In 
the latter case, a flag bad is set to true. The flag bad is also set to true when 
the adversary successfully forges. Consequently, upperbounding the probability 
that bad gets set to true in game A serves to upperbound the adversary's forging 
probability. 

Game A'. We begin by making a couple of quite trivial changes to game A. 
First, instead of setting C[m] = M[m] © Y [m] (in line 24 of game A), we set 
C[m] — M[m]0* ® Y[m], instead. That is, we imagine returning the "full" 
final-ciphertext-block instead of the truncated final-ciphertext-block. Clearly 
the extra bits given to the adversary cannot make worse an optimal adversary's 
chance of successful forgery. Second, instead of returning (in line 30 of game A) a 
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Initialization: 

01 bad <- false; for all x e {0, l} n do tt(x) <— undefined 

02 L^-{0,l} n ; 7r(0 n )<-L 

When A asks query (TV, M): //q such queries will be asked 

10 Partition M into blocks M[l] • • • M[m] 

11 X{0}^-N®L; y[0]4-{0,l} n 

12 ifX[Q] € Domain(Tr) then { bad *- true; Y[0] <- tt(X[0]) } else 

13 if Y[0] € Range(7r) then { bad <- true; Y[Q] Range(7r) } 

14 n(X[0]) Y[0] 

15 for i *- 1 to m do Z[i] <- 7i • L 0 K [0] 

16 for 2<— 1 torn- 1 do { 

17 4- M[i] © Z[z]; y[i] *i {0, l} n 

18 if X[i] € Domain(7r) then { bad <- true; y[i] <- 7r(X[i]) } else 

19 if Y[i] € Range(?r) then { bad <- true; Y[i] 4- Range(Tr) } 

20 irpT[i]). 4- y [»]; C[i] *- Y[i] © Z[»] } 

21 X[m] <- len(M[m]) © huge * L © Z[m]; y[m] 4- {0, l} n 

22 if X[m] 6 Domain(7r) then { bad <— true; Y[m] <— ^(A^m]) } else 

23 if y[m] € Range(7r) then { bad <— true; Y[m] 4- Range(7r) } 

24 7r(X[m]) <- y[m]; C[m] <- M[m] © y [m] 

25 Checksum «- M[l] © • • • © M[m - 1] © C[m] 0* © y [m] 

26 X[m + 1] <- Checksum © Z[m]; y[m + 1] 4- {0, l} n 

27 if X[m -f 1] e Domain(7r) then { bad «— true; Y[m + 1] < — 7r(X[m 4- 1]) }.else 

28 if Y[m + 1] € Ranged) then { bad <— true; y [m + 1] 4- Range(7r) } 

29 7r(X[m+l])^y[m+l]; T <— y [m + 1] [first r bits] 

30 return C <- C[l] • - - C[m] T 



Fig. 4. Game A, part 1. This game provides adversary A a perfect simulation of OCB [Perm(/i), r]. 

tag T which is the first r bits of Y [m + 1] , we return the full tag, Y [m + 1] . Once 
again, the extra bits provided to the adversary can only improve an optimal 
adversary's chance of success. Let game A' denote this new, "easier" game. We 
will bound the probability that bad gets set to true in game A'. 

Game B. Next we eliminate from game A the statement which immediately 
follows bad being set to true in each of lines 12, 13, 18, 19, 22, 23, 27, and 28. 
The else statements are also eliminated. This new game, game B, is shown 
in Figure.6. This new game is different from game A', and an adversary A 
having queries answered according to game B will not be seeing the same view 
as one whose queries are answered according to A'. Still, game B has been 
constructed so that it behaves identically to game A until the flag bad is set to 
true. Only at that point do the two games diverge. As a consequence, regardless 
of the behavior of A, the probability that bad will get set to true when A plays 
game B is identical to the probability that bad gets set to true when A plays 
game A. Now we are interested in upperbounding the probability of forgery in 
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When A makes forgery attempt (N, Q): 

50 Partition 6 into C(l] • • • C[c) T 

51 X[Q] <— N ®L; if X[0\ 6 Domain(Tr) then Y[0] <- tt(X[0]) else Y[0] £ Range(Tr) 

52 tv(X[0]) <- y[o] 

53 for i <- 1 to c do Z[i] <— 7i • L © y[0] 

54 for i «— 1 to c — 1 do { 

55 <- c[«] e z[i] 

56 if € Range(Tr) then <- Tr" 1 ^]) else ^ Domain(Tr) 

57 7r(X[i]) «- y[i]; Af [t] 4- X\i\ © Z[t] } 

58 X[c] <- len(C[c]) © /"Jge • L © Z[c] 

59 if X[c] e Domain(Tr) then y[c) <- w(X[c]) else Y[c] i RiHie"(7r) 

60 7r(X[cj) y[c] 

61 Checksum <- M[l] © • • • © M[c - 1] © C[c| 0* © Y[c] 

62 X[c + 1] <- Checksum © Z[c] 

63 if X[c + 1] € Domain(Tr) then y [c + 1] «- tt(X[c]) else y[c + 1] *i Range(Tr) 

64 T' y[c -I- 1] [first r bits) 

65 if T = X' then bad «- true 



Pig. 5. Games A, A' B, B', and C, part 2. 



Initialization: 

01 bad +- false; for all x € {0, l} n do 7r(x) «- undefined 

02 L^{0,l} n ; n{0 n )^L 

When A asks query (N,M): //q such queries will be asked 

10 Partition M into blocks M[l] - - ■ M[m\ 

11 jqo]-/V©L; y[0]^{0,l} n 

12 if X[0] € Domain(7r) then bad <- true 

13 if y [0] 6 Range(7r) then bad <- true 

14 n(X{0]) «- y[0] 

15 for i <- 1 to m do Z[i] <- 7. ■ L © y[0] 

16 for i i— 1 to m - 1 do { 

17 A-[t]*-M[i)©Z[i]; y[i]-{0,l} n 

18 if X[i] € Domain(7r) then bad <— true 
;19 if Y[i] 6 Range(7r) then bad <— true 

20 «- C[i] «- Y\i] © } 

21 X[m] <- \en(M [m]) © huge ■ £ © Z[m]; y[m] 4I {0, 1}* 

22 if X[m] 6 Domain (-nr) then bad +— true 

23 if Y[m] € Range(7r) then bad <— true 

24 v(X[m\) <- y [m]; C[m] <- M[m] 0* © Y[m\ 

25 Checksum <- M[l] © * • . © M[m - 1] © C[m] 0* © Y[m] 

26 X[m+ 1] <- Checksum ©Z[m]; K[m + 1] ^ {0, 1}" 

27 if X[m + 1] 6 Domain(7r) then bad <— true 

28 if y[m + 1] € Range(7r) then bad <- true 

29 ir(X[m + l]) «-y[m+l] 

30 return C <- C[l] • • • C[m) Y\m + 1] 



Fig. 6. Game B, part 1. 
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game A, which we do by upperbounding the probability that bad gets set to true 
in game A', which is just the probability that bad gets set to true in game B. 

Note that we are not claiming that the probability of the adversary forging 
in game B (meaning that bad gets set to true at line 65 of game B) is the same 
as the probability of the adversary forging in A' (meaning that bad gets set to 
true in the last line of that game). Claims of this sort are tempting to make, 
but they are untrue. 

Bounding Y-Collisions in Game B. We next bound the probability that bad 
will be set to true in any of lines 13, 19, 23, or 28 of game B. In each of these 
lines, a random 7i-bit string was just chosen and then it is tested for membership 
in the growing set Ranged). In the course of game B, the size Range(jr) starts 
off at 0 and then grows one element at a time until it reaches a final size of 
a + 2q + 1 elements. Therefore, the probability that, in growing Range(^r), there 

is a repetition as we add in random points is at most (1 + 2 H h o + 2q)/2 n < 

(or + 2q + l) 2 /2' l+1 . We note this for future reference: 



Pr[A causes bad to be set in any of lines 13, 19, 23 or 28 of game B] 
< (<r + 2<7 + l) 2 



(1) 



Having bounded the probability that bad will be set in the four indicated lines, 
we may imagine eliminating these four lines, forming a new game, game B'. The 
probability that bad is set in game B is at most the computed bound more than 
the probability that bad is set in game B'. Thus we may continue the analysis 
using game B' as long as we compensate the final bound by adding in the term 
given by Eq. (1). 

Game C. In game B', consider the distribution on strings returned to the 
adversary in response to a query (N, M), where m = ||M|| n . The adversary 
learns C = C[l] ■ • C[m - l]C[m] Y [m + 1]. Since each block of this string is 
a uniform random value xor'ed with some other, independent value, we have 
that C is uniformly distributed and independent of the query M, apart from 
its length. As a consequence, when a query of N, M is made, where M has 
m blocks, we can return a random answer C (of nm + n bits) and do no more 
at that time. Later, when the adversary is done making its q queries, we can 
set the remaining random values, make the associated assignments to and 
set the flag bad, as appropriate. This is what has been done in Game C of 
Figure 7. Prom the adversary's point of view, game B' and game C are identical. 
Furthermore, the probability that bad gets set to true is identical in the two 
games. 

Game Z). We have reduced the problem of upperbounding the forging proba- 
bility to the problem of upperbounding the probability that bad gets set to true 
in game C. This probability is over the coins used in line 11 of game C (which 
defines the C r -values) and over the additional coins used subsequently in the 
program. We must show that, over this sequence of coins (remember that the 
adversary is deterministic) the flag bad is rarely set. 
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When A asks its r-th query, (AT r , M r ): //r will range from 1 to q 

10 Partition M T into blocks M r [l] • • ■ M r [m r ] 

11 C r [1], - . .,C r [m r ], Y T \m + 1] 4- {0, l} n 

12 return e r «~ C r [l] • ■ ■ C r [m r ] y r [mr + 1] 

When A is done making oracle queries: 

20 bad <— false; for all x e {0, l} n do tt(x) <- undefined 

21 L^{0,l} n ; ?r(0 n )<-L 

30 for r <— 1 to q do { 

31 X r \0] *-N T ®L; Y r [0\ £ {0, l} n 

32 for i 1 to m r do 2 r [z] <- 7< • L e Y r [0] 

33 for i «- 1 to m r - 1 do { X P [i] 4- M r [i] © Z r [z]; Y r [»] <- C r [iJ 0 Z r [i] } 

34 X r [m r ] +~ len(M[Tnr)) © huge • £ © Z r [m r ] ; Y r [m r ] «— C r [mr] © M r [m r ] 0* 

35 Checksum r <- M r [l] © * • ■ © M r [m T - 1] © C r [m r ] 0* © Y^mr] 

36 X r [m r 4- 1] +- Checksum r © Z r [m r ] } 

37 AT^-(A'i[0] J A'i(l] I ... l A'i[mi + l], X q {0], X 9 [l] t . . . , X 9 [m 9 + 1]) 

38 y^-(yi|o] l yi[i] l ... I yi[mi + i] l .... y 9 [o] 1 y 9 [i],...,y 9 K + i)) 

39 if some string is repeated in X U {0 n } then bad *— true 

40 for i <- 1 to |^| do n(X[i\) y[i] 



Fig. 7. Game C, part 1. This game provides adversary A with the same view as game B, and sets 
bad with the same probability. But it defers some random choices. 

We will show something stronger: that even if one fixes all of the coins used 
in line 11 (the C r -values) and takes the probability over just the remaining 
coins, still the probability that bad gets set to true is small. The virtue of 
this change is that it effectively eliminates the q interactive queries from the 
game. Namely, since the adversary A is deterministic and each response C r 
has been fixed, the adversary can be imagined to "know" all of the queries 
iVi, Mi, . . . , N q , M q that it would ask and all of the answers Ci, . . . , C q that it 
would receive. All the adversary has left to do is to output the forgery attempt 
(N, CT). This value too is now predetermined, as our adversary is determin- 
istic. So the adversary is effectively gone, and we are left to claim that for any 
Ni, Mi, . . . , N qy M q , Ci, . . . , C q , N 9 C, 7 1 , the flag bad will rarely be set if we 
run game C starting at line 20. The new game is called game D. It depends 
on Ni, Mi, ... 9 N q , M q , Ci, . . . , C q , N, C, T, which are now just constants. The 
constants are not quite arbitrary: the N r -values are still required to be distinct. 
The lengths of Mi, . . . , M q are mi, . . . , m q blocks. The length of C is c blocks. 

The Mcoll n and MMcoll n Terms. At this point we make the observation that 
bad will be set to true in line 40 of game D if and only if either 

— There is some r e [l..q] such that there is a repetition in the multiset 

{0*, Xrl0] t Xrll],...,X r bn r )} 

— There is some pair r, s € [l..g], where r < s, such that {X r [0] , . . . X r [m r + 1] } 
has some a point in common with {X s [0], . . .X s [m s + 1]}. 
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20 bad +- false; for all x 6 {0, l} n do n(x) <— undefined 

21 L± {0, l} n ; 7r(0 n ) <- L 

30 for r <— 1 to q do { 

31 Xr[0]^N r ®L; r r [0]^{0,l} n 

32 for i <- 1 to m r do Z r [i] <- 7< ■ L © y r [0] 

33 for i <- 1 to m r - 1 do { X r \i] <- Af r [«] e Z r [i]; K r [t] <- C r [i] © Z T [i] } 

34 X r [m r ] 4— \en(M[m r ]) © huge • L © Z r [m r ] ; Cr[m, r ] 0 M r [m r ] 0* 

35 Checksum r <- M r [l] © ■ • ■ © M r [m r - 1] © C r [m r ] 0* © y r [m r ] 

36 X r [m r + 1] «— Checksum r © Zrl 771 *-] } 

37 *«-(X 1 [0l,A' 1 [l] l ...,*i[mi + l], X,[0],X,[l],...,X ff [m, + l]) 

38 y«-(y 1 [o],yi[i] I ...,y l [m l + i], .... y,[oi,y fl [i],... I y,[m 9 + i]) 

39 for i 1 to |;t| do v(X[i)) <- 3>[»] 

40 if some string is repeated in X U {0 n } then bad <— true 

50 X[0] «— TV © L; if X[0] e Domain(Tr) then y [0] — tt(X [0]) else Y[0] Ranie(7r) 

51 tt(x[o]) «- y[o] 

52 for i «- 1 to c do <— 7, • Z, © y [0] 

53 for i <- 1 to c - 1 do { 

54 y [i] 4- C[»] © Z\i] 

55 if y [t] € Range(Tr) then X[i] <- tt" 1 ^ [i]) else Domain(Tr) 

56 n( X \}]) <~ Y[ib M i i \ <- *M © } 

57 X[c] <- len(C[c]) © huge • L © Z[c] 

58 if X[c] 6 Domain(Tr) then Y[c] <- n(X[c]) else Y[c] +i Range(?r) 

59 7r(X[c]) 4- yjc] 

60 Checksum <- M[l] © ■ ■ ■ © M[c - 1] © C[c] 0* © Y[c] 

61 X[c + 1] «- Checksum © Z[c] 

62 if X[c + 1] € Domain(Tr) then Y[c + 1] <- wpf [c]) else y[c + 1] «! Range(?r) 

63 T' y[c+ 1] [first r bits] 

64 if T - T f then bad <- true 



Fig. 8. Game D. This game depends onN u ... t N q , Mi, ... , M g , Ci, . . . , C g , Y x [mi + 1], . . . , Y q 
[m q + 1], N y C — C[l] • • • Clc], and 7\ 

The probability of this event is at most 

Mcoll„(/n r )+ ^2 MMcoll rt (m r ,m s ) (2) 

r€[l..g] l<r<s<g 

r 

by our definition of Mcoll n and MMcoll„. Therefore, the probability that bad is 
set to true in line 40 of Game D is at most the expression above. We are left 
now to focus on the probability that bad gets set to true in line 64 of Game D 
(Figures 8 and 5). 

Game E. We modify the second half of game D (lines 20-39 are unchanged). 
First, we simplify lines 50, 55 and 58, and 62 by choosing a random value in 
{0, l} n as opposed to a value in the co-range, co-domain, co-range, and co-range 
of n , respectively. By similar reasoning to that used before, this new game may 
decrease the probability that bad gets set to true, but by an amount that is at 
most 

(c + 2)(or + 2q + c + 3) 
2* 
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50 X[0]<-iV@L 

51 if N ^ N r for any r and X[0] € Domain (n) then bad <— true 

52 if N = N r for some r then Y[0) «- Y r [Q] else Y[0] {0, l} n 

53 n(X[Q]) <- Y[0] 

54 for i 1 to c do Z[i] <— 7i ■ £ © y[0] 

55 for i <— ltoc — 1 do { 

56 Y[i] <- C\i) © Z[t| 

57 if Y[i\ € Range(Tr) then X{i] <- Tr'^V [t]) else X[t] ^ {0, 1}" 

58 *(X[i]) <- Y[i}; M[i\ <- X[i\ © } 

59 X[c] <- len(C[c]) © huge • L © Z[c] 

60 if X[c] € Domain(Tr) then V [c] <- tt(X[c]) else Y[c] 4- {0, l} n 

61 tt{X[c\) <- y[c] 

62 Checksum <- Af [1] © ■ ■ • © Af [c - 1] © C[c] 0* © Y[c) 

63 X[c + 1] <- Checksum © Z[c] 

64 if X[c+ 1] G Domain(7r) then bad true 



Fig. 9. Game E, part 2. The first half of this game is lines 20-39 of Game D. 

Second, we modify the game so as to "give up" (set bad) if the condition of line 62 
is satisfied. In doing this, we may again decrease the probability that bad will 
be set to true. But the decrease is at most l/2 r since, when the else clause 
of the new line 62 is executed (that is, Y [m + 1] 4- {0, 1}"), T will equal T 
with probability exactly 1/2 T . Finally, we modify the game to give up (set bad) 
whenever N g [Ni, ...,N q }, but X [0] = N 0 L is already in Domain(jr ) when 
this is checked at line 50. The new game is called game E and it is shown in 
Figure 9. We note for future reference: 

Prlbad gets set in game D] 

t^rz. j , . • " m , (c + 2)(a+2g+c+3) 2 1 

< Pr [bad gets set in game E] H — p 1 . (3) 

2 n 2 r 

Game R We now examine game E and relate it to a final game, F. If bad is 
set to true in game E the reason is either that X [0] = N ® L was found to be in 
the domain of n even though N is a new nonce, or else X [c + 1] was found to be 
in the domain of n when this was checked. In the latter case, how did X [c + 1] 
come to be in the domain of n? At least one of the following must be true: 

— X [c '+ 1] = 0 n . (The value 0" was added to the domain of n at line 21.) 

— For some r e [l..g], for some j e [0..m r + 1], X[c + 1] = X r [j]. (These values 

were added to the domain of n at line 39.) 
— For some i € [0..c], X[c + 1] = X[i\. (These values were added to the domain 

of 7t at lines 53, 57, and 61). 

When bad is set to true we will assign responsibility for this event to exactly 
one index r e [l..q]. We say that the responsible index is r where: 

— If N is a new nonce and X[0] e Domain^ ) at line 51, then the responsible 

index is the least r e 11.. q] such that X r [j ] = X [0] for some j . Otherwise, 
— If X[c + 1] = 0", then the responsible index is r — 1. Otherwise, 
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— If there is an r e [l..g] such that, for some j € [0..m r + 1], X[c + 1] = X r [j] y 
then the responsible index is the least such value r . Otherwise, 

— The responsible index is r = 1. (This last case can happen when X[c + 1] = 
X[i] for some i e [0..c].) 

Partition the coins used in the running of game E into the coins sq used in 
the initialization step (line 21); the coins s\ t ...,s q used for processing message 
Mi, ... t M qy respectively (line 31); and the coins s used to process the forgery 
attempt C (lines 52, 57, and 60). Suppose we eliminate the for statement at 
line 30, and execute lines 31-36 for some specific value of r. Call this game E r . 
We make the crucial observation that if bad is set to true in game E using 
coins (so, si, . . . , s q , s) then bad will still be set to true in game E r using coins 
(so, s r , s) when the responsible index is r. This follows from our definition of the 
responsible index. The only observation that is needed is that when X [c + 1] = 
X [i] for some i e [0..c], then, considering the least such i, if X[i] was selected 
by assigning to it an already-selected X S \J] -value, then the third case in the 
definition of the responsible index will result in the selection of an index r that 
forces bad to true. 

By what we have said, one can bound the probability that bad gets set to true 
in game E by summing the probabilities that bad gets set to true in game E r , 
where r e [l..q]. Game E r is precisely the game that was used to define the 
CMcoll ft ; in particular, the probability that bad is set in E r is CMcoll ra (c, m r ). 
We conclude that the probability that bad is set to true in game E r is at most 
CMcoll n (c, m r ). Thus the probability that bad gets set to true in game E is at 
most 



Summing Eqs. (1M4) gives that the adversary's chance of forgery is at most 



Using that (a + A) 2 - a 2 > 2a A and (a + A) 2 — a 2 > A 2 , we can increase a by 
a small amount in order to compensate for the lower-order terms and clean up 
the expression. Namely, increasing a by 2q + 1 is enough to take care of the 
first addend, while increasing a by c + 2 plus 2(c 4- 2) plus V2(c + 3) is enough 
to take care of the second addend. So increasing a by 2q + 5c + 11 will take care 
of both. Letting a = 2q -f- 5c + 11, we thus have that the adversary's chance of 
forgery is at most 




(4) 




+ 



(q + 2q + l) 2 + 2(c 4- 2)(q + 2q + c + 3) _1. 

2/t+i + 2 r ' 




This completes the proof of the structure lemma. □ 
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8.3 Proof of the M- and MM-Collision Bounds (Lemma 2) 

We assume that m,m < 2"~ 2 , since the specified probability upper bound is 
meaningless (it exceeds 1) otherwise. According to remarks we have made ear- 
lier, this ensures that yi, . . . , y m ax{m,mf » huge are distinct nonzero field elements. 

We begin with the first inequality. There are m + 3 points in the set Xq, 
and we claim that for any two of them, the probability that they coincide is at 
most 1/2". This is enough to show the first inequality, that the probability of 
a collision within Xq is at most C^ 3 ) * 2~". There are a few cases to consider. 
Below, remember that L and R are random, and everything else is constant. 
The probabilities are over L, R. In the following, we let i, V e [l..m — 1], i ^ i'. 

— Pr[X[-l] = X{0]} = Pr[0" = M[0] ®L] = 1/2". 

— Pr[X[-l] = X[i]] = Pr[0" = M[i] ©y r L®fl] = 1/2". 

— Pr[X[-l] = X[m]] = Pr[O rt = M[m] © (y m 0 huge) . L 0 R] = 1/2". 

— Pr[X[-l] =X[m+l]] = Pr[0" = M[m + 1] © y m . L © fl] = 1/2". 

— Pr[Z[0] =XU]) = Pr[Af [0] 0 L = M[i] 0 y> • L 0 ft] = 1/2". 

— Pr[X[0] =X[m}] = Pr[M[0] 0 L = M[m] 0 (y m 0 /iw#e) • L 0 22] = 1/2". 

— Pr[X[0] = X[m + 1]] = Pr[M[0] 0 L = M[m + 1] 0 y m • L 0 R] = 1/2". 

— Pr[Z[£] = Xfc']] = Pr[MH ©y r L = M[i f ] 0 • L] = Pr[M[i] 0 M[i'] = 

(n ®n>)-L] = 1/2" because y; ^ ^. 
— Pr[Z [£] = X[m]] = Pr[M[i] 0 n • L 0 E = M[m] 0 (y m 0 huge) • L 0 fl] = 

Pr [M H 0 y, • L = M [m] 0 (y m 0 /iu#e) . L] = Pr[M [j] 0 M [m] = (y m 0 huge 0 

y;) • L] = 1/2" because y* 0 y m # /iw#e. The reason that /*u#e is that 

fcu#e begins with a 1 in bit position 1, while neither Yi nor y m do, because 

i, m < 2"~ 2 and # < 2i, y m < 2m. 
— Pr[X\i] = X[m + 1]] = Pr[M[i] © y £ • L © # = M[m + 1] 0 y m * L © i?] = 

Pr[M[i] © M[m 4- 1] = ( W 0 y m ) • L] = 1/2". 
— Pr[Z[m] = X[m+1]] = Pr[M[m]®(y m @huge)-L®R = M[m+l]©y m .L©i?] = 

Pr [M[/n] © M[m + 1] = few^e . L] = 1/2". 

This completes the first inequality 

For the second inequality, we wish to show that for any point in X and any 
point in X , the probability that they coincide is at most 2~". The result follows, 
since there are at most (m + 2)(m + 2) such pairs. Remember, below, that L, i2, 
and R are random, and everything else is constant. We let i e [L.m - 1] and 
; e [l..m-l].As before, yi, . . . , y m , huge are distinct nonzero points. 

— Pr[X[0] = Jt[0]] = Pr[M[0] © L = iQT[0] © L] = 0, since M[0] ^ M[0] by 
assumption. 

— Pr[X[0] = Xlj]] = Pr[M[0] © L = it? [j] © y, : . L © R] = 1/2" due to the 
influence of R. 

— Pt[X[0] =X[m]= Pr[M [0] © L = M[m] © (y A © /m#e) * L © R] = 1/2" due 

to the influence of R. 
— Pr[X[0] =X[m + l] = Pr[M[0] ©L = M[m + 1] © Yrh • L © 5] = 1/2" due to 

the influence of R. 
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— Pt[XU] = Xlj]] = Pr[M[i] © yi • L © R = M[j] © yy ■ L © R] = l/2 n due to 
the influence of 5. 

— Pr[X[i] =X[m]] = Pr[ilfU]©w-L©J? = M[m]©(y,n©/m#e).L©i?] = 1/2" 
due to the influence of R . 

— Pr[X[i] = X[m + 1] = Pr[M[i] © yj • L © R = M[m + l]©y^.L©^] = 1/2" 

due to the influence of R . 
— Pr[X[m] = X[m] = l/2 n , as before, due to the influence of R. 
— Pr[X[m] = X[fh + 1] = 1/2" for the same reason. 
— Pr[X[m + 1] = X[m + 1] = l/2 n for the same reason. 

The remaining cases follow by symmetry. This completes the proof. □ 
8.4 Proof of the CM-Collision Bound (Lemma 3) 

At the top level, we consider two cases: N ^ N and N = N. The second of these 
will be analyzed by breaking into four subcases. 

Case 1: N ^ N. In this case there are two ways for bad to be set to true: it 
can happen at line 31 or line 44 in the game that defines the CMcoll n collision 
probability (Figure 3). Let us first calculate the probability that bad is set to 
true at line 31, which is 

Pr[bad is set at line 31] = Pr[iV © L e {0 n , X [1], . . . , X [m + 1]}] 

Note that the point X [0] = N © L in the domain of n has been omitted from set 
B = {0 n , X[l], . . . , X[m\ y X[m + 1]}, and we know this point is different from 
N © L since N / N. The probability above is taken over L and R, where each 
X [i] implicitly depends on both. We claim that for each of the m + 2 values in B, 
the probability that N © L is equal to this particular value is exactly l/2 n . This 
is verified by 

— Pr[JV © L = 0 n ] = l/2 n because of the random L. 

— For any j e [l..m - 1], Pr[iV ©L - Xlj]) = Pr[AT © L = Si [j] © Yj . L ©i?] = 
1/2" because of the random R. 

—Similarly, Pr[iV © L = M[m] © (y^ © huge) • L © R] = l/2 n because of the 
random R. 

— Similarly, Pr[i\T©L = &[m+l]] = Pr[iV©L = Checksum'© y^L ©5] = 1/2" 
because of the random R . 

We conclude that 

Pr[bad is set at line 31] < . (5) 

We next show that 

Pr[Z[c] e Domain(Tr) at line 40] < c + ™ + 3 m (6) 

2" 

For this, let us define S to be 

S = {0 n , X[Q] 9 X[l],...,X\m + l] 9 Z[0],Z[l],...,Z[c-l]}. 
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This is the domain of it at the time that line 40 is executed. The set has c + m + 3 
points and we shall use the sum bound to see that the probability that X [m] is 
one of these is at most (c + fh + 3)/2 n . Namely, 

— Pr[X[c] = 0 n ] = Pr[len(C[c]) 0 (y m 0 huge) • L 0 i? = 0 n ] = 1/2* as the 
right-hand side of the equality sign does not depend on R. 

—Pt[X [c] = X [0]] = PrOen(C[c]) 0 (y c 0 fcutfe) - L©fl=#©L] = l/2 n for the 
same reason. 

—For j e [l..m-l],Pr[len(C[c])0(y c 0/i^e).L0i? = M{j]^yj -L®R] = 1/2" 

for the same reason. 
— Pr[X [c] = X [fh\\ = Pr[len(C[c]) 0 (y c 0 /m#e) • L 0 R = M[m] 0 {ym © ^e) • 

L 0 5] = l/2 n for the same reason. 
— Pr[X [c] = [m + 1]] = Pr[len(C[c]) 0 (y c 0 huge) LqR = Checksum' 0 . 

L 0 5] = l/2 n for the same reason. 
— Pr [X [c] = X [0]] = Pr[len(C[c]) 0 (y c 0 /iu#e) .L®R=N®L] = 1/2" for the 

same reason. 

— For i e [l..c — 1], is determined in one of two possible ways: either it is 
a value already placed into the Domain(7r) (the then clause at line 37 was 
executed) or else it is a randomly selected value in {0, l} n (the else clause 
was executed). In the former case, the sum bound has already accounted for 
the probability of a collision with X[i]. In the latter case, the chance of the 
random value colliding with X [c] = len(C[c]) 0 (y c 0 huge) • L 0 R is l/2 n . 

Equation (6) has now been established. 
Next we observe that 

<* 

Pr[X[c + 1] € Domain^ ) at line 44 \X[c\& Domain(jr) at line 40 ] 

< ° + ™ + 4 . (7) 

The reason is that, when the conditioning event happens, Y [c] is selected as a 
random point in {0, l} n at line 40, which results in Checksum being a random 
value independent of the points in the domain of 7r, which results in X [c + 1] 
being a random value independent of the points in the domain of x. Since the 
domain of n has at most l + (m + 2)-j-(c + l) = c + m + 4 points at this time, 
Eq. (7) follows. Now, summing Eqs. (5M7) gives us that 

Prlbad gets set | Case 1] < 3m+ ^c + 9 (8) 

Case 2 A: N = N and c # m. The next case we consider is when N — ft 
and c # m. Redefine S to be 

S = {0 n t X [0], . . . , X [m + 1], X [1], . . . , X [c - 1] }. 

This is Domain(7r) at the time line 40 is executed. We show that 

Pr[X[c] e S | Case 2a] < ° + ™ + 2 . (9) 
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To show this, one has as before to go through the c + m + 2 points of S: 

— Pr[X[c] = 0 n ] =Pr\len(C[c])®{Y e ®huge)-L®R =0 n ] = l/2 n . 

— Pt[X[c] = N © L] = Pr[len(C[c]) 0 (y c 0 huge) -L®l?=iV®L] = 1/2*. 

—For j € [l..m - 1], Pt[X[c] = ^[/]] = Pr[len(C[c]) 0 (y c 0 feu^e) - L0fl = 
M\J] 0 yj : ■ L 0 R] = Pr[len(C[c]) 0 = ()/,• 0 y c © Ziu^e) • L] = 1/2" since 
yj © y c ^ /iu^e. The reason that y 7 ©y c ^ huge is that y 7 < 2j < 2m < 
2 . 2 n " 2 = 2"" 1 , so yj begins with a 0-bit; and y c < 2c < 2m < 2 • 2 n ~ 2 = 2 rt -\ 
so y c begins with a 0-bit; so the xor of Yj and Yc begins with a 0-bit, while 
huge begins with a 1-bit, so they are certainly unequal. 

— Pr[X[c) = X[m]] = Pr[len(C[c]) 0 (y c 0 huge) * L © R = len(M[m]) © ( Y m © 
huge)-L®R) = Prnen(C[c])©len(M[m]) = (y c ©y^)-L] = 1/2" since y c # y A 
(since c # wi). 

— Pr [X [c] = X[/h + 1]] = Pr[len(C[c]) 0 (y c 0 huge) • L © R = Checksum' © y^ - 
L © i2] = Pr[len(C[c]) © Checksum' = (y c © /iz^e © Ym) • I<] = 1/2" as before. 

— For i e [l..c - 1], either X[i] was selected as a value already in Domain^), 
in which case the sum bound has already accounted for the probability of a 
collision with X [c] , or else X [i] was selected as a new random value, in which 
case it has a l/2 n chance of colliding with X[c]. 

We have established (9). Next, as before, if X[c] & S then Y [c] is chosen at 
random, making Checksum random, and making X [c + 1] random. Thus 

Pr[X [c + 1] e Domain(7r ) at line 44 | X [c] $ Domain^ ) at line 40 ] 



since the size of the domain of n at line 44 is at most c + fh + 3. Adding Eqs. (9) 
and (10) we have that 

Pr[bad gets set | Case 2A] < 2c + 2 ™ + b (n) 



Case 2B: N = N and c = fh and 3 a, a < c, such that C[a] ^ C[a]. In this 
case, let a > 1 be the smallest index such that C[a] ^ C[a] . We claim that y [a] 
is almost certainly not in the range of it when this point is examined at line 37, 
when i = a. In fact, we claim something stronger: that Y [a] is almost certainly 
different from every point in 

S = {L, r[0],...,r[c + l], y[l],...,F[a-l], y[a + l],...,y[c-l]}. 

In particular, 

Pr[y[aUS] < C ^p~. (12) 

This is verified by going through each point in S, exactly as before. This time, 
for each point in S except Y[a], the probability that this point coincides with 
y [a] is exactly l/2 rt . The probability that ? [a] = Y[a) is 0, since C[a] ^C[a). 
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Now we modify the game that defines CMcoll n so that X [a] is always selected 
at random from {0, l} n . If we bound the probability that bad gets set in this new 
game and then add to it the bound of Eq. (12), the result bounds the probability 
that bad gets set in Case 2B. From now on in this case analysis, assume this 
new game. 

Next we claim that X [c] is almost certainly different from X [a] : 

Pr[Xlc]=X[a]) = 1 (13) 

This is clear because, in the modified game we have described, X [a] is now 
chosen at random, independent of X[c] = len(C[c]) © (huge © y c ) • L © i?. 

We may now modify the game once again so that Y [c] is selected at random 
even in the case that X [c] —X [a] . Bounding the probability of bad being set in 
the new game, and adding in the bound of (13), serves to bound the probability 
of bad being set in the prior game. 

Now we can look at the probability that X [c + 1] e Domain^ ) when this is 
checked in the modified game. At this point, the domain of n contains the 2c + 3 
points 

Domain* = {0 n , X[0],...,X\m+l], X[l], . . . , X[a], . . . , X[c}}. 

We want to know the probability that X [c + 1] = Checksum © y c • L © R is 
in this set. The value Checksum now contains the point X[a]> which, in the 
modified game, has just been selected at random and independent of all points 
in Domain* with the exception of X [a] itself. So for each of these 2c -f 2 points, the 
probability that it coincides with X[c + 1] is 1/2*. For the one remaining point 
X [a], note that Pr[X [c + 1] — X [a]] = l/2 ft , as the probability can be rewritten 
as Pr[y c • L © R = Checksum'], where Checksum' (which is Checksum without 
the X [a]) is independent of L and R. Thus 

Pt[X[c + 1] e Domain(7r) in the modified game] < c + ^ ^ Q4) 

Summing Eqs. (12H14), we conclude that 

Pr[bad gets set | Case 2B] < 2 ° + ^ + 4 . (15) 

Case 2C: N — N and c —rh and C [i] = C [i] for all 1 < i < c and \C [c]\ = 
\C [c] | . In this case, necessarily C[c] [c] . Note that Checksum has a known 
value, which is different from Checksum', being exactly Checksum' © C [c] 0* © 
C [c] 0*. The values M[l], . . . , M[c - 1] are likewise known, being identical to 
M[l], . . . , M[c — 1], respectively We are interested in 

Pr [X lc + 1] e {0", X [0] , . . . , X [el X lc + 1] }. 

One goes through each of the points, as before, and sees that the probability 
that X [c + 1] = Checksum © y c • L © R is any one of them is 1/2", except for 
the last point, for which the probability that they coincide is 0. Thus 

c 4- 2 

Pr[bad gets set | Case 2C ] < (16) 
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Case 2D: N — N and c — m and C[i] ~ C [i] for all 1 < i < c and \C [c]| # 
\C [c]|. For this case, we first claim that X[c] is almost certainly not in the 
domain of n when this is inspected at line 40 of Figure 3. The method is as 
before. The point X[c] is certain to be different from X[c], and its chance of 
coinciding with any of the c + 2 points in {0", X [0], X [1], . . . , X [c - 1], X [c + 1]} 
is easily verified to be 1/2". Thus 

Pr[X[c] € Domain(Tr) at line 40 ] < ^-J-^. (17) 

2 rt 



Proceeding as before, 

Pr[X[c + 1] e Domain(jr) at line 44 | X[c] g Domain^ ) at line 38 ] < 



c + 3 
2" 

(18) 



since c + 3 bounds the size of the domain when line 44 is executed, and the 
conditioning event ensures a random value for X [c + 1] that is independent of 
these points. Summing the bounds of Eqs. (17) and (18) gives 

Pt[X[c + 1] e Domain(jr) at line 44 ] < 2 ° + 5 . (19) 

2 n 

Conclusion. Taking the maximum from Eqs. (8), (11), (15), (16), and (19) we 
have 

Pr[bad gets set ] < ^™ ^_^ C ~*~ ^ 

which is the lemma. 

8.5 Proof of the Privacy Bound (Lemma 4) 

The proof is straightforward compared to authenticity, so we quickly go though 
it. We begin by following the proof of the Structure Lemma (Section 8.2). 
Games A to D are defined as before, except that 

— The second half of each game is omitted, since there is no forgery attempt in 
this context. 

— Return the truncated final-ciphertext-blocks, instead of the full final- 
ciphertext blocks, as the games specify. 

Focus on the (modified) game C, where we have now returned to the adversary A 
a random string of \M r \ + t bits, whenever a query M r is asked. Furthermore, 
the behavior of game C coincides with the behavior of the original game A 
unless the flag bad is set to true, at which point the two games diverge. Thus 
we can bound AdVocB[Perm(n),r]^) by bounding the probability that the flag bad 
is set to true in (the modified) game C, which is at most the probability that 
it gets set in Game D. From the same reasoning as in the structure lemma, 
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this is at most 



inax < ^2 Mcoll n (m r )-f ^ MMcoll„(m r , m s ) 

Y^ m i=<* \rt[\..q\ \<r<s<q ^ 

mj >1 

which is precisely the bound given by the the lemma. □ 



APPENDIX: BRIEF HISTORY 

An April '99 paper by Gligor and Donescu gives an authenticated-encryption 
scheme called PCBC [Gligor and Donescu 1999]. Though the mode is not cor- 
rect, as pointed out by Jutla [2000a], it may have contributed to the subsequent 
development of correct modes. Jutla's paper [Jutla 2000a] gives the first cor- 
rect schemes, IACBC and IAPM. Shortly after that paper appeared, Gligor 
and Donescu [2000a] described a different scheme, XCBC, which is similar to 
IACBC. The most conspicuous difference between XCBC and IACBC is the for- 
mer's use of mod-2" addition where the latter uses xor or mod-p addition, for p 
a prime just less than 2 n . 

A first call by NIST for modes of operation brought contributions [Gligor 
and Donescu 2000b; Jutla 2000b] based on Gligor and Donescu [2000a]; Jutla 
[2000a], and a contribution by Rogaway [2000] that built on Jutla [2000a]. In 
Jutla [2000b], he employs a Gray-code ordering for combining basis offsets, a 
refinement independently introduced in Rogaway [2000]. 

A second call by NIST gave rise to Gligor and Donescu [2000c]; Jutla [2001b], 
and Rogaway et al. [20001a], which were revisions to Gligor and Donescu 
[2000b]; Jutla [2000b]; and Rogaway [2000], respectively. In Jutla [2001b], the 
author emphasized IAPM over IACBC, and he adopted "lazy mod-p addition" 
as described in Rogaway [2000]. Gligor and Donescu [2000c] described four 
authenticated-encryption modes, one of which, XECBS-XOR, is parallelizable. 
The modes adopt some features introduced in Rogaway [2000] to deal with 
messages of arbitrary length and to use a single block-cipher key. In Rogaway 
et al. [20001a], the authors settled on one mechanism to make offsets (three 
are described in Rogaway [2000]) and made further refinements to Rogaway 
[2000]. 

Briefly comparing OCB and IAPM, the latter uses two separate keys and is 
defined only for messages that are a multiple of the block length. Once a padding 
regime is included, say obligatory 10* padding, ciphertexts will be longer than 
OCB's by 1 to n bits. IAPM supports offset-production using either lazy mod-p 
addition or an xor-based scheme. The latter is not competitive with OCB in 
terms of key-setup costs. 

An earlier version of this paper was published as Rogaway et al. [20001b]. 

The history above ignores associated patent applications. 
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ABSTRACT 

We describe a parallelizable block-cipher mode of operation 
that simultaneously provides privacy and authenticity. OCB 
encrypts-and-authenticates a nonempty string M G {0, 1}* 
using |"|M|/n] + 2 block-cipher invocations, where n is the 
block length of the underlying block cipher. Additional over- 
head is small. OCB refines a scheme, IAPM, suggested 
by Charanjit Jutla. Desirable properties of OCB include: 
the ability to encrypt a bit string of arbitrary length into 
a ciphertext of minimal length; cheap offset calculations; 
cheap session setup; a single underlying cryptographic key; 
no extended-precision addition; a nearly optimal number 
of block-cipher calls; and no requirement for a random IV. 
We prove OCB secure, quantifying the adversary's ability 
to violate the mode's privacy or authenticity in terms of the 
quality of its block cipher as a pseudorandom permutation 
(PRP) or as a strong PRP, respectively. 
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1. INTRODUCTION 

Background. An authenticated-encryption scheme is a 
shared- key encryption scheme whose goal is to provide both 
privacy and authenticity. The encryption algorithm takes 
a key, a plaintext, and a nonce (often called an IV), and it 
returns a ciphertext. The decryption algorithm takes a key, 
a ciphertext, and a nonce, and it returns either a plaintext 
or a special symbol, Invalid. In addition to the customary 
privacy goal, an authenticated-encryption scheme aims for 
authenticity: if an adversary should try to create some new 
ciphertext, the decryption algorithm will almost certainly 
regard it as Invalid. 

An authenticated-encryption scheme can be constructed 
by appropriately combining an encryption scheme and a 
message authentication code (MAC), an approach used per- 
vasively in practice and in standards. (Analyses of these 
methods are provided in [7, 24].) But an extremely attrac- 
tive goal is an authenticated-encryption scheme having com- 
putational cost significantly lower than the cost to encrypt 
plus the cost to MAC. The classical approach for trying to 
do this is to encrypt-with-redundancy, where one appends a 
noncryptographic checksum to the message before encrypt- 
ing it, typically with CBC mode. Many such schemes have 
been broken. Recently, however, Charanjit Jutla has pro- 
posed two authenticated-encryption schemes supported by 
a claim of provable security [21]. Virgil Gligor and Pompiliu 
Donescu have described a different authenticated-encryption 
scheme [15], We continue in this line of work. 

OCB MODE. This paper describes a new mode of opera- 
tion, OCB, which refines one of Jutla's schemes, IAPM [21]. 
OCB (which stands for "offset codebook" ) retains the prin- 
cipal characteristics of IAPM: it is fully parallelizable and 
adds minor overhead compared to conventional, privacy- 
only modes. But OCB combines the following features: 
- Arbitrary-length messages + minimal- length ciphertexts: 
Any string M G {0, 1}* can be encrypted; in particular, 
\M\ need not be a multiple of the block length n. What 
is more, the resulting ciphertexts are as short as possible; 
plaintexts are not padded to a multiple of n bits. 



196 



— Nearly optimal number of block- cipher calls: OCB uses 
[|M|/n] + 2 block-cipher invocations (excluding a block- 
cipher call assumed to be made during session setup). 
(It is possible to make do with |"|M|/n] 4- 1 calls, but 
such alternatives seem to be more complex or require a 
random IV.) Keeping low the number of block-cipher calls 
is especially important when messages are short. 

— Minimal requirements on nonces: Like other encryption 
modes, OCB requires a nonce. The entity that encrypts 
chooses a new nonce for every message with the only re- 
striction that no nonce is used twice. Schemes that re- 
quire non-repeating nonces are less likely to be misused, 
and often more efficient, than those requiring random IVs. 

— Efficient offset calculations: As with [15, 21], we require 
a sequence of offsets. We generate these in a particularly 
cheap way, each offset requiring just a few machine cycles. 
We avoid the use of extended- precision addition, which 
would introduce endian dependency and might make the 
scheme less attractive for dedicated hardware. 

— Single underlying key : The key used for OCB is a sin- 
gle block-cipher key, and all block-cipher invocations are 
keyed by this one key, saving space and key-setup time. 

Achieving the properties above has required putting together 
a variety of "tricks" that work together in just the right way. 
Many earlier versions of the algorithm were rejected by the 
authors because attacks were found or a proof could not be 
pushed through. We have found schemes of this sort to be 
amazingly "fragile" — tweak them a little and they break. 
We have concluded that, if the goals above are ever to be 
sought, they must be carefully addressed from the start. 

Performance. On a Pentium III processor, experiments 
by Lipmaa [25] show that OCB is about 6.5% slower than the 
privacy-only mode CBC. The cost of OCB is about 54% of 
the cost of CBC encryption combined with the CBC MAC. 
These figures assume a block cipher of AES128 [34]. 

In settings where there is adequate opportunity for par- 
allelism, OCB will be faster than CBC. Parallelizability is 
important for obtaining the highest speeds from special- 
purpose hardware, and it may become useful on commodity 
processors. For special-purpose hardware, one may want to 
encrypt- and-authenticate at speeds near 10 Gbits/second — 
an impossible task, with today's technology, for modes like 
CBC encryption and the CBC MAC. (One could always cre- 
ate a mode that interleaves message blocks fed into separate 
CBC encryption or CBC MAC calculations, but that would 
be a new mode, and one with many drawbacks.) For com- 
modity processors, there is an architectural trend towards 
highly pipelined machines with multiple instruction pipes 
and lots of registers. Optimally exploiting such features ne- 
cessitates algorithms with plenty to do in parallel. 

Security properties. We prove OCB secure, in the sense 
of reduction-based cryptography. Specifically, we prove in- 
distinguishability under chosen-plaintext attack [3, 16] and 
authenticity of ciphertexts [7, 8, 22], As shown in [7, 22], 
this combination implies indistinguishability under chosen- 
ciphertext attack (CCA) which, in turn, is equivalent to 
non-malleability [10] under CCA [4, 23]. (Non-malleability 
refers to an adversary's inability to modify a ciphertext in a 
way that makes related the two underlying plaintexts.) Our 
proof of privacy assumes that the underlying block cipher is 
good in the sense of a pseudorandom permutation (PRP) [6, 
26], while our proof of authenticity assumes that the block 



cipher is a strong PRP [26]. Our results are quantitative; 
the security analysis is in the concrete-security paradigm. 

We emphasize that OCB has stronger security properties 
than standard modes. In particular, non-malleability and 
indistinguishability under CCA are not achieved by CBC, 
or by any other standard mode, but these properties are 
achieved by OCB. We believe that the lack of strong secu- 
rity properties has been a problem for the standard modes 
of operation, because many users of encryption implicitly 
assume these properties when designing their protocols. For 
example, it is common to see protocols which use symmet- 
ric encryption in order to "bind together" the parts of a 
plaintext, or which encrypt related messages as a way to 
do a "handshake." Standard modes do not support such 
practices. This fact has sometimes led practitioners to in- 
correctly apply the standard modes, or to invent or select 
wrong ways to encrypt with authenticity (a well-known ex- 
ample is the use of PCBC mode [27] in Kerberos v.4 [29]). 
We believe that a mode like OCB is less likely to be misused 
because the usual abuses of privacy-only encryption become 
correct cryptographic techniques. 

By way of comparison, a chosen-ciphertext attack by Ble- 
ichenbacher on the public-key encryption scheme of RSA 
PKCS #1, v.l, motivated the company that controls this 
de facto standard to promptly upgrade its scheme [9, 28]. 
In contrast, people seem to accept as a matter of course sym- 
metric encryption schemes which are not even non- malleable. 
There would seem to be no technical reason to account for 
this difference in expectations. 

The future. We believe that most of the time privacy is 
desired, authenticity is too. As a consequence, fast authen- 
ticated encryption may quickly catch on. OCB has already 
appeared in one draft standard — the wireless LAN standard 
IEEE 802.11— and it is also under consideration by NIST. 

2. PRELIMINARIES 

Notation. If a and b are integers, a < 6, then [a.. b] is the 
set {a, a + 1, . . . , b}. Hi > 1 is an integer then ntz(i) is 
the number of trailing 0-bits in the binary representation of 
i (equivalently, ntz(i) is the largest integer z such that 2 Z 
divides i). So, for example, ntz(7) = 0 and ntz(8) = 3. 

A string is a finite sequence of symbols, each symbol being 
0 or 1. The string of length 0 is called the empty string 
and is denoted e. Let {0, 1}* denote the set of all strings. 
If A, B 6 {0, 1}* then A I?, or A \\ B, is their concatenation. 
If A e {0, 1}* and A # e then firstbit(A) is the first bit of A 
and iastbit( J 4) is the last bit of A. Let i,n be nonnegative 
integers. Then 0* and l 1 denote the strings of i 0's and 
l's, respectively. Let {0, l} n denote the set of all strings 
of length n. If A € {0,1}* then \A\ denotes the length 
of A, in bits, while ||A|| n = max{l, f|>l|/n]} denotes the 
length of A in n-bit blocks, where the empty string counts 
as one block. For A 6 {0, 1}* and \A\ < n, zpad n (^4) is the 
string A 0 n ~ ,yV| . With n understood we will write AO* for 
zpad n (A). If A £ {0, 1}* and r € [0..\A\] then A (first r bits] 
and A [last r bits] denote the first r bits of A and the last r 
bits of A, respectively. Both of these values are the empty 
string if r = 0. & lf A, B € {0, 1}* then A®B is the bitwise xor 
of A [first £ bits] and B [first £ bits], where £ = min{|A|, 
(where e®A = A®e = s). So, for example, 1001©11 = 01. If 
A ~ a n -i ■ • -a\ao € {0, l} n then str2num(j4) is the number 
Y^~Q 2ia i- If a € [0..2 n - 1] then num2str n (a) is the n- 
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bit string A such that str2num(A) = a. Let \en n (A) = 
num2str n (|A|). We omit the subscript when n is understood. 

If A - a„_ia n -2 • * *aia 0 € {0, l} n then A<A is the n-bit 
string a n _2a n _3 • • • aiaoO which is a left shift of A by one bit 
(the first bit of A disappearing and a zero coming into the 
last bit), while A^>\ is the n-bit string 0a n -ia n -2 • • -aiax 
which is a right shift of A by one bit (the last bit disappear- 
ing and a zero coming into the first bit). 

In pseudocode we write "Partition M into M[l] * * * M[m]" 
as shorthand for "Let m = ||M|| n and let M[l], . . . , M[m] 
be strings such that M[l] * • ■ M[m] — M and \M[i]\ = n for 
1 < i < m." We write "Partition C into C[l] • ■ • C[m) T n 
as shorthand for "if |e| < r then return Invalid. Other- 
wise, let C = C [first |C| - r bits], let T = Cjlast r bits], 
let m = ||C|| n , and let C[l], . . . ,C[m] be strings such that 
C[l] • * • C[m] = C and \C[i]\ = n for 1 < i < m. Recall that 
\\M\\ n = max{l, n^l/ n l}) so tne empty string partitions 
into m = 1 block, that one block being the empty string. 

The field with 2 n points. Let GF(2 n ) denote the field 
with 2 n points. We interchangeably think of a point a in 
GF(2 n ) in any of the following ways: (1) as an abstract point 
in a field; (2) as an n-bit string a n -i . . . aiao € {0, l} n ; (3) as 

a formal polynomial a(x) = a n -ix n-1 H ,+ aix 4- ao with 

binary coefficients; (4) as an integer between 0 and 2 n — 1, 
where the string a £ {0, l} n corresponds to the number 
str2num(a). For example, one can regard the string a = 
0 1 25 101 as a 128- bit string, as the number 5, as the polyno- 
mial x 2 1, or as an abstract point in GF(2 128 ). 

To add two points in GF(2 n ), take their bitwise xor. We 
denote this operation by a © 6. To multiply two points in 
the field, first fix an irreducible polynomial p n (x) having 
binary coefficients and degree n: say the lexicographically 
first polynomial among the irreducible degree n polynomials 
having a minimum number of nonzero coefficients. For n = 
128, the indicated polynomial is pi2s(x) = x 128 4x 7 -hx 2 -l-x4 
1. To multiply a, 6 6 GF(2 n ), which we denote a • 6, regard 

a and b as polynomials a(x) = a n -ix n_1 H \-a\x-\-ao and 

6(x) = £> n -ix n-1 + •• • + 6ix + 6oj form their product c(x) 
over GF(2), and take the remainder one gets when dividing 
c(x) by Pn(x). 

It is computationally simple to multiply a € {0, l} n by x. 
We illustrate the method for n = 128, in which case multi- 
plying a = a n -i ■ • a>\ao by x yields a n -ix n 4 a n -2X n_1 4 
aix 2 4- aox. Thus, if the first bit of a is 0, then a * x = a<l. 
If the first bit of a is 1 then we must add x 128 to a<Cl. 
Since pi 2 s(x) = x 128 4 x 7 4 x 2 + x 4- 1 = 0 we know that 
x 128 = x 7 4 x 2 4 x 4 1, so adding x 128 means to xor by 
0 120 10000111. In summary, when n = 128, 

_ f a<l if firstbit(a) = 0 

a x ~ \ (a<g:l)©0 120 10000111 if firstbit(a) = 1 

It is similarly easy to divide o € {0,1} 128 by x (i.e., to 
multiply a by the multiplicative inverse of x) . If the last bit 
of a is 0, then a x" 1 is o^>l. If the last bit of a is 1 then we 
must add (xor) to a>l the value x -1 . Since x 128 = x 7 4 x 2 4 
x 4 1 we have that x" 1 = x 127 + x 6 + x 4 1 = 10 120 1000011. 
In summary, when n = 128, 

-i _ / a>1 if lastbit(a) = 0 

a ' x " \ (o>l) © 10 120 1000011 if lastbit(a) = 1 

If L € {0, l} n and i > -1, we write L(i) as shorthand for 
L • x*. Using the equations just given, we have an easy way 



to compute from L the values L(-l), L(0), L(l), . . L(/z), 
where fi is small number. 

Gray codes. For £ > 1, a Gray code is an ordering 
7* = (70 7i ... 7^-1) of i 0 ' 1 }^ sucn tnat successive 
points differ (in the Hamming sense) by just one bit. For 
n a fixed number, OCB makes use of the "canonical" Gray 
code 7 = 7 n constructed by 7 1 = (0 1) and, for £ > 0, 
7 m = (0y e 0 Orf ••• <h&_ 2 07^.! l72*_i H<-2 *" H 
I70). It is easy to see that 7 is a Gray code. What is more, 
for 1 < i < 2 n - 1, 7i = 7i-i © (0 n ~ 1 Kntz(i)). This makes 
it easy to compute successive points. 

We emphasize the following characteristics of the Gray- 
code values 71, 72, ... , 72^-1: that they are distinct and dif- 
ferent from 0; that 71 — 1; and that 7* < 2i. 

Let L 6 {0, l} n and consider the problem of successively 
forming the strings 71 * L, 72 ■ L, 73 • L, . . ., 7 m ■ L. Of course 
71 ■ L = 1 * L — L. Now, for i > 2, assume one has already 
produced 7,-1 • L. Since 7* = 7i-i © (0 n-1 l<g;ntz(i)) we 
know that 7* • L = (7,-1 © (0 n_1 l<Cntz(i))) • L = (7^1 ■ 
L) © {^-H^ntzii)) • L = ( 7 i-i • L) © (L • x nt2 (^) = ( 7i _! ■ 
L) © L(ntz(i)). That is, the ith word in the sequence 71 • 
L, 72 • L, 73 • L, . . . is obtained by xoring the previous word 
with L(ntz(i)). Had the sequence we were considering been 
71 • L © R, 72 * L © R, 73 ■ L © R, . . the ith word would be 
formed in the same way for i > 2, but the first word in the 
sequence would have been L © R instead of L. 

3. THE SCHEME 

Parameters. To use OCB one must specify a block cipher 
and a tag length. The block cipher is a function E : JC x 
{0, l} n — > {0, l} n , for some number n, where each E(K, ■) = 
Ek{ ) is a permutation on {0, l} n . Here K, is the set of 
possible keys and n is the block length. Both are arbitrary, 
though we insist that n > 64, and we discourage n < 128. 
The tag length is an integer r 6 [0..n]. By trivial means, 
the adversary will be able to forge a valid ciphertext with 
probability 2~ r . The popular block cipher to use with OCB 
is likely to be AES [34]. As for the tag length, a suggested 
default of r = 64 is reasonable. Tags of 32 bits are standard 
in retail banking. Tags of 96 bits are used in IPSec. 

We let OCB-E denote the OCB mode of operation us- 
ing block cipher E and an unspecified tag length. We let 
OCB [£,7-] denote the OCB mode of operation using block 
cipher E and tag length r. 

Nonces. Encryption under OCB mode requires an n-bit 
nonce, TV. The nonce would typically be a counter (main- 
tained by the sender) or a random value (selected by the 
sender). Security is maintained even if the adversary can 
control the nonce, subject to the constraint that no nonce 
may be repeated within the current session (that is, during 
the period of use of the current encryption key). The nonce 
need not be random, unpredictable, or secret. 

The nonce N is needed both to encrypt and to decrypt. 
Typically it would be communicated, in the clear, along with 
the ciphertext. However, it is out-of-scope how the nonce is 
communicated to the party who will decrypt. In particular, 
we do not regard the nonce as part of the ciphertext. 

Definition of the mode. See Figure 1 for an illustration 
of OCB, and see Figure 2 for the definition. The latter fig- 
ure defines OCB encryption and decryption, while the key 
space K, is the key space for the underlying block cipher E. 
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Figure 1: Illustration of OCB encryption. The message is M = M[1]M[2] • • • M[m — l]M[ra] and the nonce is TV. 
The resulting ciphertext is e = C[1]C[2]C[3] • • * C[m-l}C[m] T. The Checksum is M[l]©- • -©M[m-l]©C[m] 0*©Y[m]. 
Define L = £*:(0 n ), Z[l] = L © R, and, for i > 2, Z[i] = Z[» - 1] © L(ntz(t)). 



Algorithm OCB.Enc*: (TV, M) 
Partition AT into M[l] • • • M[m] 
L^E K (O n ) 
R<-E K (N@L) 

for i <— 1 to m do Z[i] = 7* • L © H 

for i 4- 1 to m - 1 do C[i] <- £?jr(Af [i] © Z[i]) © Z[i] 

X[m) «- len(M[m]) © L ■ x" 1 © Z[m] 

Y[m\ <- ^(X[m|) 

C[mj I *-y[m]©M[m] 

C *- C[l] • * • C[m) 

Checksum <- M[l] © ■ • ■ © M[m - 1] © C[m] 0* © Y[m] 
T <- ^(Checksum © Z[m]) [first r bits] 
return Q <— C \\T 



Algorithm OCB.Dec/c (TV, 6) 

Partition C into C[l] • * • C\m) T 

L^E K (0 n ) 

R^E k (N®L) 

for i +- 1 to m do Z[i] - 7» • L © R 

for i <- 1 to m - 1 do M[i] <- S* 1 © Z M) © Z W 

X[mJ «- len(C[m]) © L • x" 1 © Z[m] 

r[m] Ek(XH) 

M[m] ^Y[m]®C[m] 

M 4- M[l]---M[m] 

Checksum *- M[l] © • • * © M[m - 1] © C[m] 0* © Y[m] 
T' <- (Checksum © Z[m]) [first r bits] 
if T = T f then return M 

else return INVALID 

Figure 2: Definition of OCB. Encryption and de- 
cryption are specified, while key generation chooses 
a random element from the key space /C of the block 
cipher. 



An equivalent description. The following description 
may clarify what a typical implementation might do. 

Key generation: Choose a random key K K. for the 
block cipher. The key K is provided to both the entity that 
encrypts and the entity that decrypts. 

Session setup: For the party that encrypts, do any key- 
setup associated to block-cipher enciphering. For the party 
that decrypts, do any key-setup associated to block-cipher 
enciphering and deciphering. Let L <— £?x(0 n ). Let m 
bound the maximum number of n-bit blocks that any mes- 
sage which will be encrypted or decrypted may have. Let 
fj, <— [log 2 m]. Let L(0) <— L and, for i € compute 
L{i) «— L{% — 1) ■ x using a shift and a conditional xor, as 
described in Section 2. Compute L(— 1) <— L -x -1 using a 
shift and a conditional xor, as described in Section 2. Save 
the values £(-1), £(0), L(l), . . ., L(/z) in a table. 

Encryption: To encrypt plaintext M € {0,1}* using key 
K and nonce TV 6 {0, l} n , obtaining a ciphertext C, do the 
following. Let m |"|M|/n~|. If m = 0 then let m <— 1. Let 
M[l],...,M[m] be strings such that M[l] • • • M[m] = M 
and \M[i]\ = n for i € [l..m - 1]. Let Offset <- E K {N © 
L). Let Checksum «— 0 n . For i <— 1 to m — 1, do the 
following: let Checksum <— Checksum © M[i]\ let Offset <— 
Offset ©L(ntz(i)); let C[i] *~ E K (M[i] ©Offset) ©Offset. Let 
Offset <- Offset ©L(ntz(m)). Let Y[m\ <- £ K (len(M[m]) © 
L(-l) © Offset). Let C[m] <- M[m] xored with the first 
|M[m]| bits of Y[m]. Let Checksum Checksum © Y [m] © 
C[m) 0*. Let T be the first r bits of ^(Checksum ©Offset). 
The ciphertext is C = C[l] • • • C[m - l]C[m] T. It must be 
communicated along with the nonce TV. 

Decryption: To decrypt ciphertext C E {0, 1}* using key 
K and nonce TV € {0, l} n , obtaining a plaintext M € {0, 1}* 
or an indication Invalid, do the following. If j G | < r then re- 
turn Invalid (the ciphertext has been rejected). Otherwise 
let C be the first |C| - r bits of C and let T be the remaining 
r bits. Let m |"|C|/n]. If m = 0 then let m — 1. Let 
C[l], . . . , C[m] be strings such that C[l] • ■ • C[m] = C and 
\C[i}\ = n for i € [l..m - 1]. Let Offset *- Ek(TV © L). Let 
Checksum <— 0 n . For i <— 1 to m — 1, do the following: let 
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Offset «- Offset©L(ntz(i)); let M[i] «- E^ x {C[i) ©Offset) 0 
Offset; let Checksum <— Checksum © M[i\. Let Offset <— 
Offset © L(ntz(m)). Let r[m] — E K (\en(C[m]) © L(-l) © 
Offset). Let M[m\ C[m] xored with the first |C[m]| bits of 
Y\m). Let Checksum «- Checksum ©y[m]©C[m] 0*. Let T 
be the first r bits of ^(Checksum ©Offset). If T ^ T' then 
return Invalid (the ciphertext has been rejected). Other- 
wise, the plaintext is M — M[l] • • - M[m — l]M[m]. 

4. DISCUSSION 

OCB has been designed to have a variety of desirable prop- 
erties. Some of these have been discussed in the Introduc- 
tion. We extend that discussion here. 

Arbitrary-length messages and no ciphertext ex- 
pansion. One of the key characteristics of OCB is that any 
string M € {0, 1}* can be encrypted, and doing this yields 
a ciphertext C of length \M\ + r. That is, the length of the 
"ciphertext core" — the portion C = C[l] * • *C[m] of the ci- 
phertext that excludes the tag — is the same as the length of 
the message M. This is better, by up to n bits, than what 
one gets with conventional padding. 

Single block-cipher key. OCB makes use of just one 
block-cipher key, K. While L — Ek{^ u ) functions rather 
like a key and would normally be computed at session-setup 
time, and while standard key-separation techniques can al- 
ways be used to obtain many keys from one, the point is 
that, in OCB, all block-cipher invocations use the one key K. 
Thus only one block-cipher key needs to be setup, saving on 
storage space and key-setup time. 

Weak nonce requirements. We believe that modes of 
operation that require a random IV are often misused. As 
an example, consider CBC mode, where C[i] = Ek{M[i\ © 
C\i — 1]) and C[0] = IV. Many standards and many books 
(e.g., Schneier, Applied Cryptography, 2nd edition, p. 194]) 
suggest that the IV may be a fixed value, a counter, a time- 
stamp, or the last block of ciphertext from the previous mes- 
sage. But if it is any of these things one certainly will not 
achieve any of the standard definitions of security [3, 16]. 

It is sometimes suggested that a mode which needs a ran- 
dom IV is preferable to one that needs a nonce: it is said 
that state is needed for a nonce, but not for making random 
bits. We find this argument wrong. First, a random value of 
sufficent length can always be used as a nonce, but a nonce 
can not be used as a random value. Second, the manner 
in which systems provide "random" IVs is invariably state- 
ful anyway: unpredictable bits are too expensive to harvest 
for each IV, so one does this rarely, using state to generate 
pseudorandom bits from unpredictable bits harvested be- 
fore. Third, the way to generate pseudorandom bits needs 
to use cryptography, so the prevalence of non-cryptographic 
pseudorandom number generators routinely results in im- 
plementation errors. Next, nonce- based schemes facillitate 
replay-detection with constant space and no added cryptog- 
raphy. Finally, nonces can be communicated using fewer 
bits, without additional cryptography. 

On-line. OCB encryption and decryption are "on line" in 
the sense that one does not need to know the length of the 
message in advance of encrypting or decrypting it. Instead, 
messages can be processed as one goes along, using con- 
stant memory, continuing until there is an indication that 
the message is over. 



Endian neutrality. In contrast to a scheme based on 
mod-p arithmetic (for p a prime just less than 2 n ) or mod- 
2 n arithmetic, there is almost no endian-favoritism implicit 
in the definition of OCB. (The exception is that, because 
of our use of standard mathematical conventions, the left 
shift used for forming L(i+ 1) from L(i) is more convenient 
under a big-endian convention, as is the right shift used for 
forming L(— 1) = L * x" 1 from L.) 

Optional pre-processing. Implementations can choose 
how many L(i) values to precompute. As only one block- 
cipher call is needed to compuet these values from if, plus 
some shifts and conditional xors, it is feasible to do no pre- 
processing: OCB-AES is appropriate even when each session 
is a single, short message. 

Provable security. Provable security has become a pop- 
ular goal for practical protocols. This is because it provides 
the best way to gain assurance that a cryptographic scheme 
does what it is should. For a scheme which enjoys prov- 
able security one does not need to consider attacks on the 
scheme, since successful ones imply successful attacks on 
some simpler object. 

When we say that "OCB is provably secure" we are as- 
serting the existence of two theorems. One says that if an 
adversary A could do a good job at forging ciphertexts with 
OCB[i?,r] (the adversary does this much more than a 2~ T 
fraction of the time) then there would be an adversary B 
that does a good job at distinguishing (Ek(-), E^ l (-)), for 
a random key K, from (tt(-), 7r -1 (*)), for a random permu- 
tation 7r G Perm(n). The other theorem says that if an ad- 
versary A could do a good job at distinguishing OCB[E, r]- 
encrypted messages from random strings, then there would 
be an adversary B that does a good job at distinguishing 
Ek{'), for a random key K, from 7r( ), for a random per- 
mutation 7r € Perm(n). Theorems of this sort are called 
reductions. In cryptography, provable security means giving 
reductions (along with the associated definitions). 

Provable security begins with Goldwasser and Micali [16], 
though the style of provable security which we use here — 
where the primitive is a block cipher, the scheme is a usage 
mode, and the analysis is concrete (no asymptotics) — is the 
approach of Bellare and Rogaway [3, 5, 6]. 

It is not enough to know that there is a provable-security 
result; one should also understand the definitions and the 
bounds. We have already sketched the definitions. When 
we speak of the bounds we are addressing "how effective is 
the adversary B in terms of the efficacy of adversary A" 
(where A and B are as above). For OCB, the bounds can 
be roughly summarized as follows. An adversary can al- 
ways forge with probability 1/2 T . Beyond this, the maximal 
added advantage is at most cr 2 /2 n , where a is the total num- 
ber of blocks the adversary sees. The privacy bound likewise 
degrades as cr 2 /2 n . The conclusion is that one is safe using 
OCB as long as the underlying block cipher is secure and a 
is small compared to 2 n ^ 2 . This is the same security degra- 
dation one observes for CBC encryption and in the bound 
for the CBC MAC [3, 6]. 

Comparison with Jutla's bound. More precisely, but 
still ignoring lower-order terms, our privacy and authentic- 
ity bounds are 1.5<7 2 /2 n , while Jutla's authenticity bound 
is insignificantly worse at 2a 2 /2 n and his privacy bound, 
rescaled to [0, 1], looks insignificantly worse at 3<x 2 /2 n [20]. 
Magnifying the latter difference is that the privacy re- 
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suits assume different defintions. Jutla adopts the find- 
then-guess definition of privacy [3, 16], while we use an 
indistinguishability-from-random-bits definition. The for- 
mer captures an adversary's inability to distinguish cipher- 
texts for a pair adversariily-selected, equal-length plain- 
texts. The latter captures an adversary's inability to dis- 
tinguish a ciphertext from a random string of the same 
length. Indistinguishability-from-random-bits implies find- 
then-guess security, and by a tight reduction, but find- 
then-guess secure does not imply indistinguishability-from- 
random-bits. Still, Jutla's scheme probably satisfies the 
stronger definition. 

Simplicity. Simplicity has been a central design goal. Some 
of OCB's characteristics that contribute to simplicity are: 

- Short and full final-message-blocks are handled without 
making a special case: the treatment of all messages is 
uniform, regardless of their length. 

- Only the simplest form of padding is used: append a min- 
imal number of 0-bits to make a string whose length is a 
multiple of n. This method is computationally fastest and 
helps avoid a proliferation of cases in the analysis. 

- Only one algebraic structure is used throughout the algo- 
rithm: the finite field GF(2 n ). 

- In forming the sequence of offsets, Gray-code coefficients 
are taken monotonically, starting at 1 and stopping at m. 
One never goes back to some earlier offset, uses a peculiar 
starting point, or forms more offsets than there are blocks. 

Not fixing how the nonce is communicated. We do not 
specify how the nonce is chosen or communicated. Formally, 
it is not part of the ciphertext (though the receiving party 
needs it to decrypt). In many contexts, there is already a 
natural value to use as a nonce (e.g., a sequence number 
already present in a protocol flow, or implicit because the 
parties are communicating over a reliable channel). Even 
when a protocol is designed from scratch, the number of 
bits needed to communicate the nonce will vary. 

Not fixing the tag length. The number of bits necessary 
for the tag vary according to the application. In a context 
where the adversary obtains something quite valuable from 
a successful forgery, one may wish to choose a tag length 
of 80 bits or more. In contexts such as authenticating a 
video stream, where an adversary would have to forge many 
frames to have a major impact on the image, an 8-bit tag 
may be appropriate. 

Forming R using a block-cipher call. During our work 
we discovered that there are methods for authenticated- 
encryption which encrypt M using [|M|/n] +1 block-cipher 
calls, as opposed to our f|M|/nl -I- 2 calls. Shai Halevi 
has also made this finding [17]. However, the methods we 
know to shave off a block-cipher call either require an un- 
predictable IV instead of a nonce, or they add conceptual 
and computational complexity to compute the initial off- 
set R by non-cryptographic means (e.g., using a finite-field 
multiplication of the nonce and a key variant). 

Avoiding M0D-2 n addition. Our earlier designs included 
a scheme based on modular 2 n addition ( "addition" for the 
remainder of this paragraph). Basing an authenticated- 
encryption scheme on addition is an interesting idea due to 
Gligor and Donescu [15]. Compared to our GF(2 n )-based 
approach ("xor" for the remainder of this paragraph), an 



addition-based scheme is quicker to understand a specifica- 
tion for, and may be easier to implement. But the use of 
addition (where n > 128) has several disadvantages: 

- The bit-asymmetry of the addition operator implies that 
the resulting scheme will have a bias towards big-endian 
architectures or little-endian architectures; there will be 
no way to achieve an endian-neutral scheme. The AES 
algorithm was constructed to be endian-neutral and we 
wanted OCB-AES to inherit this attribute. 

- Addition is unpleasant for implementations using high- 
level languages, where one normally has no access to the 
add-with-carry instruction the machine may have. 

- Addition needs more chip area than xor. 

- Addition is not parallelizable. As a consequence, dedi- 
cated hardware will perform this operation more slowly 
than xor, and, correspondingly, modern processors can 
xor two n-bit quantities faster than they can add them. 

- The concrete security bound appears to be worse with 
addition than xor (though still not bad). The degrada- 
tion would seem to be 0(lg m), where fh is the maximal 
message length. 

We eventually came to feel that even the simplicity benefit 
of addition was not quite real: these schemes seem harder 
to understand, to prove correct, and to implement well. 

Lazy MOD-p addition. Let p be the largest prime less 
than 2 n . An earlier design [31] allowed one to produce off- 
set Z[i\ from Z\i — 1] by "lazy mod-p addition" : add L to 
Z[i — 1], mod 2 n , and then add 5 = 2 n — p whenever the 
first addition generates a carry. Now X[m] would be defined 
by len(M[m]) © ^[tm], say, where Z[m] is the bitwise com- 
plement of Z[m]. It appears that, unlike a mod-2 n scheme, 
xors can still be used to combine offsets with message blocks 
and enciphered message blocks. This might make lazy mod- 
p approach more attractive than a mod-2 n approach. But in 
order to propagate a single scheme, avoid endian favoritism, 
and avoid complicating an already complex proof, we chose 
not to propagate lazy mod-p- addition. 

Definition of the Checksum. An initially odd-looking 
aspect of OCB's definition is the definition of Checksum = 
Af [1] © • • • M[m - 1] © C[m] 0* © Y[m). In Jutla's scheme, 
where one assumes that all messages are a positive multi- 
ple of the block length, the checksum is the simpler- looking 
M[l] © * • • M[m — 1] © M[m]. We comment that these two 
definitions axe identical in the case that |M[m]| = n. What 
is more, the definition Checksum = M[l] © • • • M[m — 1] © 
M[m] 0* turns out to be the wrong way to generalize the 
Checksum to allow for short- final-block messages; in partic- 
ular, the scheme using that checksum is easily attacked. 

Avoiding pretag collisions. Many of our earlier schemes, 
including [31], allowed the adversary to force a "pretag col- 
lision." Recall that we compute the tag T by computing 
a "pretag" X[m 4- 1] = Checksum © SomeOffset, forming a 
value Y[m + 1] = £/e(X[m 4- 1]), and then forming T by 
doing further processing to Y[m 4 1], For a scheme of this 
form, we say that an adversary can force a pretag collision 
if there is an Af, M that can be encrypted, getting C T, and 
then a forgery attempt AT, CT can be made such that, in it, 
the pretag X[m 4- 1] will coincide with a value X[i] or X[i] 
at which the block cipher E was already evaluated. 

We designed OCB so that an adversary can not force pre- 
tag collisions. The presence of pretag collisions substan- 
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tially complicates proofs, since one can not follow a line of 
argument that shows that tags are unpredictable because 
each pretag- value is almost certainly new. For schemes like 
IAPM, where pretag collisions can be forced, this intuition 
is simply wrong. Beyond this, in the presence of pretag 
collisions one must modify Y[m + 1] by an amount A that 
depends on at least the key and nonce. Say that the mod- 
ification is by xor, and one wants to be able to pull off an 
arbitrary bit as a 1-bit authentication tag. Then every bit 
of A will have to be adversarially unpredictable. This is un- 
fortunate, as many natural ways to make A fail to have this 
property. Suppose, for example, the first couple bits of L 
are forced to zero, as suggested by [31], and A = L • (m + 1). 
Then, for small m, the first bit of A will be zero. This can be 
exploited to give an attack on the xor-based scheme of [31] 
when r = 1. Similarly, for i a power of two, A = iL mod 2 n 
ends in a 0-bit, so had [31] taken the tag to be the last r bits 
instead of the first r bits, one would again have an attack 
on 1-bit tags. A scheme would be arcane, at best, if certain 
bits of the full tag are usable and other bits are not. 

Block-cipher circuit-depth. One further efficiency mea- 
sure is the circuit depth of an encryption scheme as mea- 
sured in terms of block-cipher gates. For OCB encryption, 
this number is three: a call to form R\ calls to form the 
cipher text core; and a call to compute the tag. Block- 
cipher circuit-depth serves as a lower bound for latency in an 
agressively parallel environment. Reducing the block-cipher 
circuit-depth to one or two is possible, but the benefit does 
not seem worth the associated drawbacks. 

5. THEOREMS 

5.1 Security Definitions 

We begin with the requisite definitions. These are not 
completely standard because OCB uses a nonce, and we 
wish to give the adversary every possible advantage (more 
than is available in real life) by allowing her to choose this 
nonce (though we forbid the adversary from choosing the 
same nonce twice). 

Syntax. We extend the syntax of an encryption scheme as 
given in [3]. A (nonce- using, symmetric) encryption scheme 
is a triple n — (/C, £, V) and an associated number n (the 
nonce length). Here K is a finite set and S and V are de- 
terministic algorithms. Encryption algorithm S takes K 6 
/C, N 6 {0,l} n , and M 6 {0,1}*, and returns a string 
C «- S K {N,M). Decryption algorithm V takes K 6 /C, 
N 6 {0, l} n , and C € {0, 1}*, and returns V K (N, M), which 
is either a string M G {0, 1}* or the distinguished symbol 
Invalid. If e <- Sk(N, M) then V K {N, e) = M. 

Privacy. We give a particularly strong definition of pri- 
vacy, one asserting indistinguishability from random strings. 
This notion is easily seen to imply more standard defini- 
tions [3], and by tight reductions. Consider an adversary A 
who has one of two types of oracles: a "real" encryption or- 
acle or a "fake" encryption oracle. A real encryption oracle, 
£tf(v)i takes as input AT, M and returns C <— £k(N,M). 
Assume that | C j — £(\M\) depends only on \M\. A fake en- 
cryption oracle, $(•, •), takes as input AT, M and returns a 
random string C £ {0, 1}^' M '*. Given adversary A and 
encryption scheme II = (/C,£,D), define Adv£ nv (<4) = 
p T [K A k, : >l f *(•••> = 1] - Pr[tf £ K : A* M = 1]. 



An adversary A is nonce-respecting if it never repeats a 
nonce: if A asks its oracle a query (N> M) it will never 
subsequently ask its oracle a query (Af,M') } regardless of 
its coins (if any) and regardless of oracle responses. All 
adversaries are assumed to be nonce- respecting. 

Authenticity. We extend the notion of integrity of cipher- 
texts of [7, 8, 22]. Fix an encryption scheme II = (£,£,£>) 
and run an adversary A with an oracle £k(*, ) for some 
key K. Adversary A forges (in this run) if A is nonce- 
respecting, A outputs (TV, e) where Vk(N,£) ^ Invalid, 
and A made no earlier query (N, M) which resulted in a re- 
sponse C. Let Advf! Uth (A) = Pr[K £■ K : A £kW) forges ]. 
We stress that the nonce used in the forgery attempt may 
coincide with a nonce used in one of the adversary's queries. 

Block ciphers and PRFs. A function family from n-bits 
to n-bits is a map E : /C x {0, l} n — + {0, l} n where JC is a fi- 
nite set of strings. It is a block cipher if each Ek(-) = E(K t •) 
is a permutation. Let Rand(n) denote the set of all functions 
from {0, l} n to {0, l} n and let Perm(n) denote the set of all 
permutations from {0, l} n to {0, l} n . These sets can be re- 
garded as function families by imagining that each member 
is specified by a string. For 7r £ Perm(n), let tt~ 1 (Y) be 
the unique string X such that n(X) = Y. Let Adv^ rf (A) — 
Pr^^-l]- Pr[A^"> = l], Adv prp (,4) = Pr[i4^<-> = 1)- 
PrfAO = 1], and Adv s £ rp (A) = Pt[A Ek( ^ b k 1 ^ = i]_ 
Pr[A ,r(,),ir ~ 1( * ) = 1], where the probability is over K £ /C, 
p Rand(n), and n A Perm(n). 

5.2 Theorem Statements 

We give information- theoretic bounds on the authenticity 
and the privacy of OCB. Proofs are in the full paper [33]. 

Theorem 1. Fix OCB parameters n and r. Let A be 
an adversary that asks q queries and then makes its forgery 
attempt Suppose the q queries have aggregate length of a 
blocks, and the adversary's forgery attempt has at most c 
blocks. Let a = a + 2q + 5c + 11. Then 

A J auth / a\ ^ 1-5 J" 2 1 

Adv OCB[Perm(n)ir] (A) < 2n + — 

The aggregate length of queries Mi , . . . , M q means the 
number a = J2l=i \\ M r Un- 
it is standard to pass to a complexity-theoretic analog of 
Theorem 1, but in doing this one will need access to an E~ l 
oracle in order to verify a forgery attempt, which translates 
into needing the strong PRP assumption. One gets the fol- 
lowing. Fix OCB parameters n and r, and a block cipher 
E : JC x {0,l} n -+ {0,1}". Let A be an adversary that 
asks q queries and then makes its forgery attempt. Suppose 
the q queries have aggregate length of a blocks, and the 
adversary's forgery attempt has at most c blocks. Let a = 
a+2q+5c+ll. Let 5 = Adv^ [£ Tj (A)-1.5a 2 /2 n -l/2 T . 
Then there is an adversary B for attacking block cipher E 
that achieves advantage Adv s £ Tp (B) > 6. Adversary B asks 
at most q f = o + 2q + c+3 oracle queries and has a running 
time which is equal to A's running time plus the time to 
compute E or E~ l at q' points plus additional time which 
is ana, where the constant a depends only on details of the 
model of computation. 

The privacy of OCB is given by the following result. 
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Theorem 2. Fix OCB parameters n and r. Let A be an 
adversary that asks q queries, these having aggregate length 
of a blocks. Let a — a + 2q + 3. Then 

15 a 2 

Adv OC V B[Perm(n),T] (^) ^ 2 n 

It is standard to pass to a complexity-theoretic analog of 
Theorem 2. One gets the following. Fix OCB parameters 
n and r, and a block cipher E : K. x {0,l} n {0, l} n . 
Let A be an adversary that asks q queries, these having 
aggregate length of a blocks. Let a — a + 2q + 3. Let 
5 = Advg£% [E r] (A) - 1.5 a 2 /2 n . Then there is an adver- 
sary B for attacking block cipher E that achieves advantage 
Adv P £ P (B) > 5. Adversary B asks at most q' - a + 2g + 1 
oracle queries and has a running time which is equal to A's 
running time plus the time to compute E at q' points plus 
additional time which is ana, where the constant a depends 
only on details of the model of computation. 

5.3 Proofs 

To prove Theorem 1 (Theorem 2 is comparatively easy) 
we give a structure lemma that relates the authenticity of 
OCB to three functions: the M-collision probability, the 
MM-collision probability, and the CM-collision probability. 
Very informally, these measure the probability of trouble 
when the adversary asks a single query, some pair of queries, 
and when adversary tries to forge some ciphertext following 
a single earlier query. Due to space limitations, all of these 
definitions, lemmas and proofs are removed from this pro- 
ceedings paper. They can be found in the full paper [33], 

6. PERFORMANCE 

Abstract accounting. OCB uses [|M|/n] + 2 block- 
cipher calls to encrypt a nonempty message M. (The empty 
string takes three block-cipher calls.) We compare this with 
CBC encryption and CBC encryption plus a CBC MAC: 

- "Basic" CBC encryption, where one assumes a random 
IV and a message which is a multiple of the block length, 
uses two fewer block-cipher calls — a total of \M\/n. 

- A more fair comparison sets IV = Ek(N) for CBC en- 
cryption (so both schemes use a not-necessarily-random 
nonce), and uses obligatory 10* padding (so both schemes 
can handle arbitrary strings). This would bring the total 
for CBC to |"(|M| + l)/n] + 1 block-cipher calls, coinciding 
with OCB in the case that \M\ is a multiple of the block 
length, and using one fewer block-cipher call otherwise. 

- If one combines the basic CBC encryption with a MAC, 
say MACing the ciphertext, then the CBC-encryption 
will use a number of block-cipher calls as just discussed, 
while the CBC MAC will use between fl^l/nl + 1 and 
|"(|M| + l)/n] +3 block-cipher calls, depending on padding 
conventions and the optional processing done to the final 
block in order to ensure security across messages of vary- 
ing lengths. So the total will be as few as 2[|M|/n] + 1 
or as many as 2[(|M| + + 4 block-cipher calls. Thus 
OCB saves between f|Af |/n| - 1 and n^|/n] + 3 block- 
cipher calls compared to separate CBC encryption and 
CBC MAC computation 

As with any mode, there is overhead beyond the block- 
cipher calls. Per block, this overhead is about four n-bit xor 
operations, plus associated logic. The work for this associ- 
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Figure 3: Performance results from Lipmaa [25], in 
cycles per byte on a Pentium III. The block cipher 
is AES128. Code is written in assembly. 



ated logic will vary according to whether or not one precom- 
puted L(i)- values and many additional details. 

Though some of the needed L(i)- values are likely to be 
precomputed, computing all of them "on the fly" is not 
inefficient. Starting with 0 n we form successive offsets by 
xoring the previous offset with L, 2 • L, L, 4 • L, L, 2 • L, 
L, 8 • L, and so forth. So half the time we use L itself; a 
quarter of the time we use 2 • L\ one eighth of the time we 
use 4 • L; and so forth. Thus the expected number of times 
to multiply by x in order to compute an offset is at most 
= 1- Each a • x instruction requires an n-bit 
shift and a conditional 32-bit xor. Said differently, for any 
m > 0, the total number of a • x operations needed to com- 
pute 7i * L, 72 • L } . . . , 7 m • L is J2iLi nt2 (0> which is less 
than m. The above assumes that one does not retain or 
precompute any L(i) value beyond L = L(0). Suppose that 
one precomputes £(—1), £(0), L(l), L(2), L(3). Computing 
and saving the four values beyond L = L(0) is cheaper than 
computing L itself, which required an application of Ek* 
But now the desired multiple of L will have be available at 
least 1/2+1/4+1/8 + 1/16 « 94% of the time. When it has 
not been precomputed it must be calculated, starting from 
L(3), so the amortized number of multiplications by x has 
been reduced to £~ t = i/2 i+4 = 0.125. 

Experimental results. In Table 3 we report, with permis- 
sion, some experimental results by Helger Lipmaa [25]. On 
a Pentium III, in optimized assembly, Lipmaa implemented 
OCB encryption, ECB encryption, CBC encryption, and 
the CBC MAC. The last three modes were implemented in 
their "raw" forms, where one does no padding and assumes 
that the message acted on is a positive multiple of the block 
length. For CBC encryption, the IV is fixed. The underlying 
block cipher is AES128. 

Focusing on messages of 1 KByte, OCB incurs about 
6.4% overhead compared to CBC encryption, and the al- 
gorithm takes about 54% of the time of a CBC encryp- 
tion + CBC MAC. Lipmaa points out that overhead is so low 
that, in his experiments, an assembly AES128 with a C-code 
CBC- wrapper is slightly slower than the same AES128 with 
an assembly OCB- wrapper. Lipmaa's (size-unoptimized) 
code is 7.2 KBytes, which includes unrolling AES128 (2.2 
KBytes) three times. 

Some aspects of the experiments above are unfavorable to 
OCB, making the performance estimates conservative. In 
particular, the "raw" CBC MAC needs to be modified to 
correctly handle length- variability, and doing so is normally 
done in a way that results in additional block- cipher calls. 
And when combined with CBC encryption, the CBC MAC 
should be taken over the full ciphertext, including the nonce, 
which would add an extra block-cipher call. Finally, an extra 
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block-cipher call would normally be performed by CBC to 
correctly compute the IV from a nonce. 

The results above are for a serial execution environment. 
In settings with plenty of registers and multiple instruction 
pipes, OCB, properly implemented, will be faster than CBC. 
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APPENDIX 

A. BRIEF HISTORY 

Jutla, Gligor-Donescu, Rogaway. An April 1999 paper 
by Gligor and Donescu gives an authenticated-encryption 
scheme called PCBC [11]. The mode is wrong, as pointed 
out by Jutla [18], but it may have contributed to the subse- 
quent development of correct modes. Jutla's paper [18] gives 
the first apparently correct schemes, IACBC and IAPM. 
Shortly after that paper appeared, Gligor and Donescu de- 
scribed a different scheme, XCBC [12], which is similar to 
IACBC. The most conspicuous difference between XCBC 
and IACBC is the former's use of mod-2 n addition where 
the latter uses xor or mod-p addition, for p a prime just less 
than 2 n . 

A first call by NIST for modes of operation brought con- 
tributions [13, 19] based on [12, 18], and a contribution by 
Rogaway [31] that built on [18]. In [19], Jutla employs a 
Gray-code ordering for combining basis offsets, a refinement 
independently introduced, along with further tricks, in [31]. 

A second call by NIST gave rise to [14, 20, 32], which 
were revisions to [13, 19, 31], respectively. In [20], Jutla 
emphasized IAPM over IACBC, and he adopted lazy mod-p 
addition, first described in [31]. In [14], Gligor and Donescu 
describe four authenticated-encryption modes, one of which, 
XECBS-XOR, is parallelizable. The modes adopt some fea- 
tures introduced in [31] to deal with messages of arbitrary 
length and to use a single block-cipher key. In [32], Rogaway 
et al. settled on one mechanism to make offsets (three are 
described in [31]) and made further refinements to [31]. 

Briefly comparing OCB and IAPM, the latter uses two 
separate keys and is defined only for messages which are 
a multiple of the block length. Once a padding regime is 
included, say obligatory 10* padding, ciphertexts will be 
longer than OCB's by 1 to n bits. IAPM supports offset- 
production using either lazy mod-p addition or an xor-based 
scheme. The latter is not competitive with OCB in terms 
of session-setup costs. 

The initial version of Jutla's work [18] claimed a proof, 
and included ideas towards one. A subsequent writeup by 
Halevi [17] was more rigorous. 

Patents. The history above ignores associated patent ap- 
plications. Jutla/IBM, Gligor/VDG, and Rogaway have all 
indicated that there were such filings. All parties have pro- 
vided statements to NIST promising reasonable and nondis- 
criminatory licensing. 

Definitions. Though the authenticated-encryption goal is 
folklore, provable-security treatments of it are recent. The 
first definition for authenticated encryption is due to Bellare 
and Rogaway [8] and, independently, Katz and Yung [22]. 
Bellare and Namprempre were the first to seriously inves- 
tigate the properties of authenticated-encryption and the 
generic-composition paradigm [7]. 
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